Software is hard: things get lost in translation

Software can be hard, especially when one is not prepared for it to be so. When something goes wrong, more often than not people are looking at the wrong place or laying blame at the wrong place. This blog provides an oversimplification of the issue.

It’s a euphemism to state that software is hard. It’s hard work. Anything seriously worthwhile is going to take grit and toil. Don’t let all the self-help marketing tell you otherwise, if you do you would actually make it even harder for yourself.

One reason software can be hard is that snowball effect is very common and can quickly result in avalanche-like consequences. So I wrote one reason, not the only reason, not the main reason, just one reason. I am not going to produce long studies, hard numbers or anything of that kind here. Instead, I give an oversimplification of the way the snowball effect, the trickle down with an ever-expanding area of influence, can be visualised.

Illustration, how small issues can trickle down
Illustration, how small issues can trickle down

Whenever something goes wrong, which is to say very often, a good way to go about finding solutions is in re-examining things all the way from the top and work your way down. Which place to start, which direction to go (top-down, or bottom-up ) is a matter of taste, choice, context, but usually just a personal one. Since, quite clearly, it is a complex matter, looking for solutions in a random manner can be extremely inefficient and may never yield any result.

A corollary of this situation is that, software can result in ever-expanding benefits if things go well. Such benefits could be much more than winning the lottery for example. If you revise the diagram, take expressions like “things can get in the way”, “human condition”, “distraction” and turn them respectively into “things can contribute”, “human insight”, “epiphany” or “serendipity”, and you have a different diagram and positive outcome.  Concerns like “fear”, “doubt”, “politics”, “unexpected changes” typically have a double-edged sword effect to them. These can have positive effects when properly leveraged, or negative effects when they actually lead us to inaction or unproductive behaviour.

With software, bad things and good things, don’t only travel top-down or bottom-up, they typically start somewhere and expand like fluid dropped on a piece of absorbing cloth.

Whether are a manager or a doer, next time people rush into quick explanations or laying blames, invite them to look just a little further, to take a deep breath, to just sleep it over, and reconsider their positions. More often than not, the outcome could be different. Taking that chance to just delay conclusions a tad is usually a good bet, a profitable investment strategy.

Leverage the best of community and agile approaches for results

It is a good idea to leverage the best of communities and agile approaches to product development in Software Architecture practices. Last semester product releases from Microsoft are indication that they are applying these concepts, Architects should learn from that.

It seems to me that Microsoft is applying some valuable lessons from open-source and community driven software processes: get user buy-in as early as possible, deliver early and frequently incomplete or partially flawed products. People will happily participate, you would get a more accurate feel for the reception when the product finally ships. I don’t know what the pundits are saying, but to me (as a software architect and user), this strategy pays off handsomely.

Every new Microsoft product I laid my hands on over last half-year has been nicely thought out and clearly user-oriented by design. You can almost feel that product development received a lot of attention, and that is good news for the 90% of us who use Microsoft software.

I’ve started using Microsoft Office 2010 Beta on my Windows 7 box. You immediately see the impact of some of the lessons they’ve learned with the previous major release, the ribbon concept has been tweaked, the experience feels more natural yet innovative. I’ve not had to spend any time reading documentation (though that would be a mistake for a final product, reading the documentation is always for the best), I had no troubles working just like before.

Similarly, when I first learned about the early Microsoft Azure visions, I was having a strange feeling of “lipstick on a pig” treatment. After PDC2009, I saw lots of improvements and change of heart on some early ideas that seem to be, without a doubt, the result of extensive community participation.

The early concepts and beta releases of SharePoint 2010 and Office 2010 have stunned me in their clarity of vision, for the first time I’m getting excited about Microsoft’s web-based software. Having spent the best part of last decade delivering non-Microsoft solutions, albeit I’ve never lost sight of what they were doing, I am seeing a lot of good vibes coming from Redmont these days.

Another potential idea that can be read here, would be that Microsoft is directly engaging users and hence doing away with their former approach where their partners supplied the bulk of feature requirements (I’ve read a lot of Michael Cusumano and Mary Jo Foley throughout the years, any misreading would be mine).

To me, these are all signs that Microsoft’s products are improving, they are increasingly addressing unmet user needs. This would be a software delivery equivalent of a “growth business”, I buy it.

I see a parallel with the practice of software architecture, whether its Enterprise Architecture or Solution Architecture on a smaller scoped project. Software Architects can achieve much success by adopting some of the same recipes hinted at earlier, by no means a complete list:

  • don’t seek completeness on any significant topic before getting stakeholder communities fully engaged (no, they won’t think you’re daft)
  • don’t think you have all the answers (many thought leaders are saying this), actively seek and incorporate ideas from the receiving parties – they’d have a hard-time to reject their own input, wouldn’t they?
  • delegate major chunks to smaller and dedicated groups, see to it that the inter-group communication is fluid and sustained (I don’t know if Microsoft does this, it seems many of their products are still large silos).

With this type of approach, the outcome tend to feel much more natural and the acceptance will probably be easier. You see it for example when, using the product, you guess how something might work and could verify that the feature was implemented almost exactly as you guessed. This happens a lot when I use Apple products. I used to think that Microsoft would never be able to match such feat, but I now see that they are changing their approach for the better.