The Quality Dilemma.
A discussion that reflects the classic software Quality dilemma:
Manager: I’m cognisant of the reasons why Quality is a very important issue. The ‘Quality Lever’ should never be tampered with.
Developer: Excellent. I’m glad you see it that way.
Manager: After all, I used to code.
Developer: Really!
Manager: I’m also wary that it’s my responsibility to ensure we conclude development as fast as possible.
Developer: Of course.
Manager: I believe part of achieving that is aiming for a reasonable standard of Quality. I’m looking to stay on the sweet spot where further effort expended on Quality adds little value � The Pareto Principle.
Developer (Thinking): Do you really understand how important Quality is? I can see that Lever moving now….
I believe the essence of development teams’ traditional response to this dilemma is: thinking less about the business problems they are solving. Spelt differently: DANGER.
What results is often this:
- Coding effort increases
- Rate of delivery may initially increase
- Bugs increase
- Communication decreases
- Attention to design considerations decrease
- Team morale decreases
- Eventually rate of delivery decreases
- The size of the code-base balloons
The code-base starts resembling the developers picture of the Domain: a convoluted mass of perplexing ideas that may stumble across solving a problem.
There Is No Dilemma.
The result is very different if the team has a fair proportion of developers who can leave the Quality lever untouched and keep churning out functionality. To these developers Quality and Craftsmanship is the development rhythm in which they thrive. To them there is no dilemma.
However if a team has an high proportion of underskilled developers, the Craftsman-like developers are in a dilemma of their own. Do they follow suit and churn out masses of pungent code? Do they bite the bullet, making a stand by educating the team about their rhythm and its concepts? It’s an interesting problem. Those with a conscious seem to err towards the latter.
I’m facing a somewhat related problem now. I’m in a situation where I believe the team has been going too fast. It needs to slow down, take a breath and consider the pollution in their wake. It’s not battle stations yet. An awareness of the state of play is needed in the group so that things can be progressively changed for the better.
The Dilemma Of Integrating Knowledge.
But onto another developer dilemma. Some of us strive to do all of:
- Refine and improve the ways we develop.
- Communicate modeling/design concepts and goals with the group.
- Pump out features fast.
This all sounds healthy but knowledge can be an evil thing. Some things learned cannot wait till the next project. They come as a revelation. ‘How could I have been blind to this? It makes so much sense!’ are words that come to mind when I reflect on these moments. Often in these situations if you don’t use that knowledge you risk your artifacts being assessed as sub-standard. So you strive to employ the techniques almost immediately. Suddenly points 2 and 3 become a problem and/or take a back seat for a moment. In a slightly different scenario, coming into a team with a different rhythm of development (i.e. different knowledge) can also lead to a similar situation.
For mind, I find handling this dilemma an extremely difficult act. At times I see pragmatism as an unacceptable compromise, at other times the practicality of progressive change.
Agile Doesn’t Always Make You Faster.
Back to the the issue of Quality or Quickness. Here’s a statement I’ll regret: Agile development is often slower in completing features than Waterfall orientated methodologies. However this is only true in situations where ‘completed feature’ does not take into account:
- The amount of bugs associated with the feature
- Integration with its numerous parts within the application
- Testing to ensure the feature is correct
In this context ‘completed’ actually means ‘I’ve written the source code for it, therefore it should work.’ Of course, usually Agile gets you to the end-game of being in production incredibly faster than these approaches.
Unfortunately, it’s little comfort to management that bugs are never born from the code-base if a Waterfall-like schedule is imposed on them with a massive allotment for pre-production testing etc. These are the environments where ‘Agile in a Bubble’ can be destructive because things appear to moving slower than usual, yet the reality is quite opposite.
The Evil Of Quality Being The Least Of Your Concerns.
A final thought, the high turnover rate in IT hurts projects for a number of reasons but often overlooked is the mindset it encourages;
Manager (Thinking): I won’t be here that long so I can afford to care less about the maintainability and extendability of the application. After all, if Quality becomes an issue I’ll be gone and the development team will probably be held accountable.
Developer (Thinking): I won’t be here that long so I can afford to pump out cruft. After all it’ll seem like I’m developing faster.
