Experiment, Adopt, Achieve

I’ve long been searching for a succinct noun phrase for that certain annoying thing that seemingly requires you to do something in a less-than-perfect way. Something that you know can and should be done better. You curse having that ‘requirement’, you loathe having to create a ‘workaround’, and you dream of a better world. Whether it’s the tardiness of the web standards world requiring CSS browser hacks, or the less-than-stellar API of an enterprise system with which you have to integrate, or perhaps being forced to browse in IE because of corporate bureaucracy, you’ve probably become annoyed at having to contend with this thing that, if the world was a better place, would not otherwise be detrimental to your work or productivity.

Having failed at finding the correct phrase for such a thing, I’ve done what I usually do and made one up. I now consider something like the above to be an illegitimate affecter. Having this succinct term is useful when identifying individual constituent parts of the system that can then be factored out by function and treated to an increase in quality (refactoring/rewriting) on a part by part basis.

For example, I sometimes stumble on poorly named properties only to trace their source back to the (poorly named) property of an outside API. The developer that first created the property in our application used the property name of the API object as an affecter but failed to recognize it as illegitimate, unnecessarily causing that little bit of extra confusion to all developers consequently working with that property.

I’ve also been in design discussions when reasons are brought up against making some architectural/design change to the system, only to be carefully exposed as illegitimate affecters, often temporary in nature, and sometimes actually even lending more weight to the argument to undertake the change proposed.

When they are outside of your control, illegitimate affecters should be kept at bay by abstraction layers. When inside your control, they themselves should form part of the redesign and refactoring discussions.

What illegitimate affecters can you think of?

A couple of weeks ago I presented at an internal company conference on Lean Software Development and what we can learn from Lean Manufacturing. As I am still a neophyte at presenting, the PowerPoint notes are prosaic and should be a coherent read.

I also included a slide discussing the Estimation Fallacy and Optimism Bias in an attempt to provide some insight into why software estimation is so often inaccurate.

The last thing I wanted to slip in was a slide on The Alignment Trap as presented in a Bain Consulting industry research publication released back in 2007. Briefly, the conclusions of this study put companies in four distinct quadrants: Well-aligned/Effective; Less-Aligned/Effective; Well-aligned/Ineffective and Less-aligned/Ineffective. The sales figures of the companies in the less-aligned/effective quadrant were better than the sales figures of the well-aligned/ineffective companies. The lesson there being that companies should avoid the alignment trap by letting their IT departments become effective at what they’re doing, before aligning IT operations more accurately with the business strategy.

It’s all in the presentation in better detail here!

When trying to get developers of a project invested in what they are doing on a day to day basis, few practices go so far as the establishment of an informal meritocracy in the team.

Traditionally in software, meritocracy is talked about with relation to initially giving a developer a small amount of time and trust to contribute something outside of his or her traditional area. The product of that time is then evaluated by the team leader or project manager, and if that mini-project was deemed to be valuable, the developer is given additional time and trust the next time he has an idea (when time permits so as not to negatively affect the main development project). This process works successfully in open source projects.

Now, I think it would be good to extend this phenomenon, contrary to the usual rules of social correctness in the workplace, to informal benefits in and around the workplace itself. Senior developers should get to work from home more, more relaxed internet surfing rules and even free coffee (if not already standard) so as to get juniors to aspire to be just like them. We are not all rewarded in equal financial terms for the value we contribute towards the project, so why should we all be subject to the same office environment rules? People should associate responsibility, accountability, and good performance with benefits beyond just their salary.

Conversely, employees who abuse the trust given to them to perform their job can have their perks reduced or taken away entirely. Is Gerald Facebooking too much? Fine, restrict him and only him to free surfing in lunch hours and after 5pm. If he’s gives a damn, he’ll soon get the message and shape up. If he doesn’t, well, taking away his perks will hopefully be the first few steps to warnings and then a dismissal, because you don’t want anyone like that on your software team.

I am aware that this kind of thing could get messy with the wrong people around, but then again, software development in general gets messy with the wrong people around! I would concede that an informal meritocracy would work best in a mature workplace where the hierarchy is accurately based on experience, qualifications and merit to the project, however rare that may be!

So let’s drop the egalitarian charade and tell it like it is. All software developers are not created equal, and differing perks for juniors and seniors would be a good thing!

In the ongoing quest to helpfully frame the dos, don’ts and whys of software engineering to management, every so often we come up with illuminating analogies that do wonders to illustrate why a software team should or should not follow a particular strategy. One very successful one is technical debt (coined by Cunningham and later helpfully expanded on by Steve McConnell). Although they can be misused, analogies generally help us to communicate to non-techies with more clarity. Having pondered on the life of my current 2yr+ project, I’ve come up with another (albeit flippant and high-level) analogy: Software is like Tetris.

A software project, with specific focus on providing ongoing value to the business as the product evolves towards feature plateau, is like a game of tetris but with one alteration: The blocks fall quicker as they stacker higher. What I mean is that the closer you are to conducting zero-overhead iteration after zero-overhead iteration, the more time (read: less pressure) you have to solve problems: engage in root cause analysis, attack process bottlenecks, conduct code reviews, lower technical debt, and several other things that don’t directly add business value but that are obviously invaluable. The converse to all this is what I experienced on the project I’m on now, but with previous management: As deadlines tighten on features having been promised to the business by overexhuberant non-techie managers, those same managers demand that nothing else be done except the implementation of the feature, the quick-and-dirty hacking in of which slows down implementation of future features. Developers are forced into increasing their estimates because implementing features into a messy codebase takes more time and carries higher risk, and managers think the wool is being pulled over their eyes. Trust ebbs away, entropy sets into the codebase, the business get unstable software, morale is sinking and your tetris blocks are piling up fast and falling quicker.

So it seems like the focus should not be on delivering a piece of software. The focus should be building a team of engineers supported by managers, testers, business domain specialists as well as the right tools and a comfortable working environment to create an entity that can sustain the delivery of features with quality and predictability. Peaks and troughs of feature quantity and quality should be rare and small tweaks and improvements should be made to aid the gradual increase of quality and quantity. Effort should be on keeping overhead low and your features should tick away like lines of blocks in a well-running Tetris game.