Sunday, December 28, 2008

The Bus Problem

Software engineering practitioners joke about this all the time, and it’s a classic management problem that is deeply rooted in the software engineering folklore. There exists a person who singlehandedly built software program that supports some important business function (in production environment of course). Everyone knows that there is virtually no documentation, no one else knows the code, there is no source control, and this is the only person who can maintain the program. And if that person gets hit by a bus and dies there will major issues, but it’s better not to think about it.

Even in the organizations that have mature software engineering processes the bus problem persists. This is because all organizations have opportunistic projects (programs) developed by a person or two. These programs, usually developed as unofficial side projects, support informal business processes that provide significant benefit to the end users at little cost. These opportunistic projects are usually developed in a haphazard way, because there is no spare time and they are targeting a very specific audience. Examples of this type of program may be a custom authentication mechanism that is small enough to be developed and maintained by a single person. Such solution may have been intended to be used for just a single software solution, but over time it became an important component of multiple software intensive solutions, or this program became the vehicle for supporting a core official business process.

My colleague responsible for a project that fits the description above has been hit by a “bus”.

Future posts will provide lessons learned from the experience written from an architect’s point of view:
• Dealing with the bus problem
• Anticipating the bus problem
• Preventing the bus problem

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Tuesday, December 16, 2008

Taking care of your people

This post is about taking care of your colleagues and employees. With holidays rapidly approaching many people scramble to say thank you and congratulate their subordinates and colleagues. This behavior often leads to awkward moments and superficial exchanges of gratitude. Don’t do it.

If you haven’t been taking care of your people through the year consider changing your behavior. By saying “taking care” I don’t mean buying expensive gifts or giving superficial awards. What I mean is enabling your colleagues and employees to support you in the most productive way possible while operating in a professional environment. In life it’s the small things that leave a lasting impression that make people happy.

Let’s say your new team members all have standard company issued laptops with 1 GB or memory. The software tools they use to model architecture and conduct analysis functions result in thrashing and frustrating usability experience. Closing Outlook and IDE makes the modeling software run fast, but that’s not the solution. Your first action is to immediately buy an additional 2 GB of RAM for each person and have it shipped express mail.

Surprise your colleagues by baking cookies from scratch. Not bringing left over batch or buying a package, but purposefully making something for the team. This element of surprise and pleasant goodness clashes with the ordinary daily routine. This is a great way to say thank you in a very small way.

Finally, create and maintain a professional working environment. This may be difficult if the rest of the organization is not ethical or the senior management doesn’t appear to care. It’s important for you, as a leader, to create a sense of belonging. You must consistently address any unprofessional behavior within your team so that your employees can concentrate on delivering the best work rather than dealing with non-work related distractions.

Enabling your team to support you with proper tools in a professional work environment through the year will make you more productive and holiday times less awkward.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...