Tag: Software engineering

Posted on

The Hero Syndrome

A “super programmer” can be 5x – 10x more productive than the average programmer. That is an astonishing difference and you will know if you ever work with one … it is obvious that they just “get it” better and faster than those around them.  Does that make them a good and valuable member of the team?  Well, maybe.

Patton once said “… a staff officer of uncongenial disposition should be relieved irrespective of any other qualities.”  Presumably including their productivity.  The point he was making was that the staff was a team and the friction caused by an ill-disposed person would be destructive to the team morale and overall team performance.

The seduction of hiring and retaining a hero is that things get done … and done fast.  The question, of course, is what gets done?  Is it the right thing that is getting done – the team’s vision of what is to be produced – or just the hero’s vision.  Tony Stark works alone … OK, with Jeeves the bot … basically alone.  He works on his vision of what is needed.

It is not impossible for a hero to be a good team player.  Take a virtuoso violinist … if the orchestra is playing Beethoven and the violinist is playing Mozart … well, he might be playing Mozart the best it has ever been played … and it will all sound like crap.

Keeping the hero on board with buy-in to the overall project and what is being developed by others can be a particular managerial challenge.  If your favorite hero can only see their own vision – rather than make the team’s vision their own – then you will have a challenge.  The hero may generate so much code so fast that it looks like waste to toss it out … easier to switch the vision.  The waste, though, was on the part of the hero … they wasted their effort on their vision rather than the team’s.  That is not to say that they mightn’t actually be correct and the team might really need to change their vision … 

Attrition.  Well, the hero rides out of town and the townsfolk are left with … themselves.  The more the organization has relied on the hero, the more difficult this is.  The team/organization has to be prepared to lose any team member … at any time … for any or no reason.  Murphy’s laws of software development includes:

  • The more important a resource is to completing development, the more likely it will be missing when needed most.
  • Corollary: If a resource is needed to complete development then it will go missing and do so at the least opportune moment.

The right way to employ a hero may be as a hired gun … a contractor … bring the hero in to solve a specific problem and then let them go.  The problem specification should include that the solution is documented so that the team can sustain it long-term.

Posted on

The Software Quality V

A software development project is often, if not usually, complicated by many moving parts. Let’s make some sense of all that.

There have been more than a few software development process models proposed over the past 50 years.  From the engineering-/architecture-based, (much-scorned) waterfall model to the present-day “agile” process.  One thing is certain … something else will eventually come down the road … and it will be presented as the final, absolute  best possible solution to the software development process woes beleaguering software projects.  And it won’t be any of those things.  But it will solve some problems (and introduce some new ones).

What can we say is pretty universally true about software development?  Well, we know a few things for sure

  • First, we need to know what we are building before we build it.  Not necessarily the ultimate end – like an architect’s rendition of a proposed building – but we do need to know what we are building next.
  • For what we are about to build … we need to have an idea of how we are going to build it.  And if we have more than 1 person working on it … they had better have the same idea of how the thing is going to be built … or you end up like this:  ___ —-  (railroad tracks that don’t marry)
  • While building it, we need to do the construction with high quality materials (that is, code … the statements that are written need to be written well – both correct and understandable).
  • Finally, when the parts are all put together, everything works together to do what we intended to do in the first place … assuming that hasn’t changed along the way …

Agile and waterfall don’t differ from each other in that requirements precede design, precedes code, precedes integration … they differ more in the fact that waterfall attempts to build the whole building while agile – with the whole building in mind – worries more about building a floor (or a room) at a time.

Where does quality fit into this picture?  At each stage of the process … there are quality tasks/activities that pair up with each of the engineering/development steps.  The usual picture is a V with the two sides of the V representing the activities of development and quality

After the introduction of the computer “terminal” which is already an archaic term – so … after punched cards … software development has always looked like “typing” (now called “keyboarding”). And it looks like anybody can do it. As you know, if you have ever tried to write (well) even a short essay … There is a big difference between writing and typing.  There is an even bigger difference between coding and writing … and typing.

Posted on

Quality is Free

Originally published in 1979, Philip Crosby’s book “Quality is Free” is a seminal work in quality – especially manufacturing quality.  The premise of the book is that defects – poor quality – often causes re-work which is expensive. 

I’m sure we have all seen it … a road gets torn up (for months) and new infrastructure is embedded under the roadway … and then it is paved over … and construction is finally over.  And then here they come back again … tear up a part of the road that had just been replaced … and put something else in … or fix something.  If it had been planned properly… or the workmanship hadn’t been shoddy … then it would have all been taken care of the first time the road was torn up.  Re-doing it cost somebody (probably us) much more then doing it right in the first place would have cost.

With respect to software, as one of the reviewer of Crosby’s book puts it: “Very good read, but I’m not sure how well it translates outside of manufacturing – the software world is not like a production line: requirements are fuzzy, the designers are also the builders, and defects often arise from emergent complexity.” Fair enough.  However, re-work in software is much more expensive than getting it right in the first place.  That is not to argue for a “waterfall” development process (more about that later) … but just to observe that adding – or correcting – a feature after it is developed is much more expensive than developing it correctly in the first place.  Studies have shown that correcting errors after the software is fielded is 30x more expensive than doing it right in the first place.

So, quality is free – in software – when the entire lifecycle of the software product is considered.  The lifetime cost of software is heavily weighted to the lifetime maintenance of the software (we’ll define exactly what that means in a later post).  Consider that there is still software running today that was written 40 years ago.

The confounding factor – and a subject of yet another, later post – is how to decide how much focus to put on quality when you have no idea whether the software will survive in the marketplace.  How do we balance the cost of quality when building a “minimum viable product?”

Posted on

What is Quality in Software?

As you might imagine, software quality assurance is the application of quality principles to software.  So starting back at the beginning … what do we mean by “quality?”

Many definitions suffer from being self-referential: “… the act or process of confirming that a firm’s quality requirements are being met.”  And those that aren’t may be too 

specific – or focused – on a particular industry.

Quality, by definition, moves from characteristic … to essential character … to superiority of kind; excellence

1a. An inherent or distinguishing characteristic; a property: the medicinal qualities of a plant.

b. A personal trait, especially a character trait: “The most vital quality a soldier can possess is self-confidence” (George S. Patton).

2. Essential character; nature: “The quality of mercy is not strain’d” (Shakespeare).

3a. Superiority of kind: an intellect of unquestioned quality

b. Degree or grade of excellence: yard goods of low quality.

And it is that final definition that works for software.  But still what does it mean for something to be “superior” or “excellent?” We all have an idea of what quality – especially high quality – is in the sense of a degree of excellence.  We especially sense its lack, when it is missing.  Which it often is in software, but I get ahead of myself …

Automobiles are a great way to discuss quality differences.   There are many examples of pretty crummy (Yugo, I’m looking at you …) to blah to meh to good (Lexus) to great (Lamborghini) vehicles … but we can all tell – often just by looking, but always by driving – where a vehicle fits on that spectrum. Often, but not always, the shoddiest goods are the cheapest – or, at least, less expensive.  Some people – like me – are willing to pay more (within reason) for higher quality products.  Why?  Well, because they are often more serviceable – a better fit for their purpose.  Or they last longer.  Or they perform and/or look better while doing it.  Note that only some of that can be measured … lasting longer, for example.  Whereas “looking better” is usually a matter of taste. 

Note: In my ‘verse it is not important what other people think of me based on what I own or use … I am more interested in the intrinsic quality of the product rather than “keeping up appearances.”  Others’ mileage most certainly varies …

Applying all this to software – my industry and, hence, my particular focus – is pretty straightforward in some of those cases – for example, fitness for use.  How well software does what it is supposed to do – if it is supposed to compute a value, does it do so accurately (so that it is correct) and reliably (so that it can repeat the calculation with the same accuracy over and over again). The more complex the system, the more challenging it is to assess IT quality.  There may be things it does well and things it does poorly so that the question then becomes one of racking and stacking the relative importance of those things it does.  And, yes, different people differ on what is more/less important.