Ok I think it's time to step in for developers. In http://www.theregister.co.uk/2012/12/21/financial_software_disasters/, Dave Mandi amuses us and points out that much code quality is low. And he - largely - beats up on the quality of developers for it. I have some sympathy for some of his arguments : in my experience, most developers have programming-language knowledge, but few know how to write applications using that language. I know many who have Development certifications but I would not "trust" to develop re-usable software components - too often, they just aren't interested enough in software design to go from programmers who can drive languages and APIs to developers who can implement software of real and lasting value. But, in my experience, many good developers don't write bad software out of ignorance : they do it because, as the author (later) acknowledges:
"In the real world, tight budgets, shortsighted managers, and unreasonable expectations from non-techies almost always conspire to make developers do things too quickly. "
Yes, that's probably the nub of it - the point when good code goes bad...when the project demands quality compromises from the design/analysis and implementation parts of the project, which mean that you just end up with stuff that is initially executable but (usually) hard to maintain, fragile, and downright nasty to work with. Nobody wants this as an outcome : but what is the reason this mostly might happen? Because the project team has over-ridden the primary rule : the customer gets to vary schedule, scope, price and resources to do a "thing", but the project team protects the implementation quality within those other variable parameters. It simply is not in the customer's interests to allow quality of implementation to be under their control. Here's an example of how this might work in a discussion:
Customer : how long will the system take to develop?Project Manager : according to my estimates, three months for an initial release with the primary use cases you have identifiedCustomer : that's too long. What can you take out?Project Manager : well, I see that each use case has a 20% loading for use cases. How about we drop those out? That'll get you into test on time.Customer : Fantastic!
Bad smell there? Feeling uneasy? Right...what happened there was, when you read...
Project Manager : Well, I see that each use case has a 20% loading for unit testing. How about we drop those out? That'll get you into test on time.
The meaning actually was:
Project Manager : Well, I see that each use case has a 20% loading for unit testing. I can ask the development team to write perfect code first time, with no need to verify results or worry about future changes. How about that? That'll get you into test on time.
That is an example of why project managers should not expose critical aspects of quality in development codebases to customers. No one (not me, not YOU) can write software that is perfect first time, given the poverty of requirements and analysis/design that is undertaken. And no code base should emerge into the light of day that is not supported by unit and coverage tests which support our beliefs about the abstract world we have created in our software. So project managers : train your customers to vary schedule, scope and cost, and leave the quality to the development teams.
But what, I hear you cry, about the fact that (anecdoteally) developers won't release anything till it is perfect? I am not sure any developer wants to write code that never sees the light of day or a slice of processor time! My mantra for developers is : the best is the enemy of the good, but make sure the good is, from a quality as well as functional perspective, complete.
"In the real world, tight budgets, shortsighted managers, and unreasonable expectations from non-techies almost always conspire to make developers do things too quickly. "
Yes, that's probably the nub of it - the point when good code goes bad...when the project demands quality compromises from the design/analysis and implementation parts of the project, which mean that you just end up with stuff that is initially executable but (usually) hard to maintain, fragile, and downright nasty to work with. Nobody wants this as an outcome : but what is the reason this mostly might happen? Because the project team has over-ridden the primary rule : the customer gets to vary schedule, scope, price and resources to do a "thing", but the project team protects the implementation quality within those other variable parameters. It simply is not in the customer's interests to allow quality of implementation to be under their control. Here's an example of how this might work in a discussion:
Customer : how long will the system take to develop?Project Manager : according to my estimates, three months for an initial release with the primary use cases you have identifiedCustomer : that's too long. What can you take out?Project Manager : well, I see that each use case has a 20% loading for use cases. How about we drop those out? That'll get you into test on time.Customer : Fantastic!
Bad smell there? Feeling uneasy? Right...what happened there was, when you read...
Project Manager : Well, I see that each use case has a 20% loading for unit testing. How about we drop those out? That'll get you into test on time.
The meaning actually was:
Project Manager : Well, I see that each use case has a 20% loading for unit testing. I can ask the development team to write perfect code first time, with no need to verify results or worry about future changes. How about that? That'll get you into test on time.
That is an example of why project managers should not expose critical aspects of quality in development codebases to customers. No one (not me, not YOU) can write software that is perfect first time, given the poverty of requirements and analysis/design that is undertaken. And no code base should emerge into the light of day that is not supported by unit and coverage tests which support our beliefs about the abstract world we have created in our software. So project managers : train your customers to vary schedule, scope and cost, and leave the quality to the development teams.
But what, I hear you cry, about the fact that (anecdoteally) developers won't release anything till it is perfect? I am not sure any developer wants to write code that never sees the light of day or a slice of processor time! My mantra for developers is : the best is the enemy of the good, but make sure the good is, from a quality as well as functional perspective, complete.
Comments