Let's have just fun

Some engineers, both junior and senior, have random approach to work as opposed to a systematic one. By random (or freestyle) approach I mean:

• generating quick ideas without followup
• kidnapping discussions with unrelated digressions
• presenting ideas without putting an effort into thinking them over
• making decisions without discussion
• organizing useless meetings
• hacking code without designing it
• not using drawings when explaining concepts or designs
• not tracking issues/tickets/projects
• not documenting

By systematic (or disciplined) approach I mean the opposite.

Balance

I get that the random approach is easier (and more fun?) and that it tends to produce new ideas. But if you use it too much it will create unnecessary chaos and technical debt after some time. In other words it will increase technical and organizational (when embraced by managers) complexity without adding value. So you need some balance between freestyle and disciplined approach. To evaluate the balance look for the signs.

The signs of unhealthy level of technical complexity in software systems:

• hard to use
• unclear API and documentation
• unclear design
• difficult to find bugs
• difficult to add new features
• difficult to take over (or hand over)
• operational problems and outages

The signs of unhealthy level of organizational complexity are:

• meetings without agenda, conclusions and followup
• people don’t show interest in the meetings
• the same problems being discussed again and again
• difficulty to schedule meetings, too many meetings
• bureaucracy and rules that make no sense
• non-existent or unclear team/company strategy and goals
• non-existent or toxic team/company culture

(You can have unnecessary complexity also on personal level but I won’t discuss this here and now.)

Simplicity

I suspect that the main reason causing this problem is underestimating the importance of simplicity.

Simplicity is actually hard. To keep things simple you have to think about them, write your ideas down and review them several times. Consider what is the goal, what resources you have, what are the pros and cons of various ways to achieve the goal. You also have to discuss your ideas and listen to other people’s ideas. Once you have somehow clear ideas you have to communicate them well. Then you have to implement them (e.g. writing some code) and organize in accordance with them (via meetings, documentation, code structure). You have to be able to resist various pressures and temptations (you must be able to say NO to most things). And you have to do all this again and again. This requires time, energy, skill, motivation, patience and persistence. On the other hand it brings satisfaction.

In case your current team/company doesn’t want or is not able to do this (and you want or are) there are three options for you:

• accept it and consider it a party instead of chaos :-)
• get into a (management) position from which you can influence things
• get into a company (which seems to be) heading in the right direction

The first option is the easiest one but not necessarily the right one. Of course you can and should always strive for simplicity on individual level. But you only have a certain amount of time, energy and patience.

Life cycle of a silver bullet

I’ve watched SRECon discussion about DevOps. They mentioned a paper from Sarah A. Sheard called “Life Cycle of a Silver Bullet”. Written in 2003. I googled it and read it and I was enlightened. (While writing this, I’ve been served tea by a robot for the first time in my life!). The paper contains several ideas I had and several observations I made while being part of an attempt to introduce something like DevOps within a company.

Sheard claims that “improvement initiatives” can and do work, but it very much depends on how they are implemented. In this post I’ll try to extract from the paper the positive and negative signals you can observe when trying to implement an improvement initiative, like DevOps or Agile.

Positive signals

Someone with power to make changes (like an executive or a manager) takes a close look how his company is working to determine problems. He also looks at company’s strengths.

You can see there is real focus and dedication (of time and money) to implement the identified improvements.

The problems are truly solved, not just glossed over.

A climate of openess without retribution is fostered, and senior managers listen to messages from all levels of the company.

Products start to be created more efficiently and with better quality.

Negative signals

Managers read only short summary articles about the improvement method.

The implementing managers ask workers to implement some specific improvements (read in the blogs) without costly discussion or modification.

Some specific improvements are ruled out with reasoning that they would be costly to implement.

Executives and managers don’t really listen to workers nor change their own way of working. What they state as improvement in communication is really only about downward communication.

Lack of executive involvement. Managers don’t involve executives because the superiors might feel threatened or embarrassed.

Dilution of emphasis.

Tendency to apply the steps as a checklist rather than to seek and fix the company’s basic business problems.

Workers feel bombarded by misuderstood management initiatives that don’t solve any real problems.