DIGG IT! I often get stuck in development on how to make something work. I keep finding that if I design targeting "Good Enough" rather than "Ideal", development is more productive and the results are much better.
First off let me clarify "Good Enough" and "Ideal":
"Good Enough" - Designing software to fully satisfy the current requirements and nothing more.
"Ideal" - Designing software to exceed the current requirements of the project.
Developing for "Good Enough" doesn't mean cutting quality but rather being practical in regard to meeting requirements, rather than exceeding them. I occasionally find myself diving into a single aspect more than is necessary. When I look back on my time spent, the single aspect coded to "Ideal" standards wasted allot of time and effort. If I had spent the wasted "Ideal" time on making things "Good Enough", the overall project would have benefited.
I guess the "Ideal" mentality emanates from attempting to defensively protect a project from changing requirements. Everyone has had a project where mid-development, the manager says in passing:
"Oh, by the way we need to support this too. Is that a problem?"
On occasion, coding for "Ideal" has saved me in these situations and falsely bolstered my confidence in the practice. Instead of remembering all the wasted effort in coding to "Ideal", I remember the rare victories where it saved me.
So from now on I am focused on coding to "Good Enough" rather than "Ideal". Hopefully I will ship more software and better meet current requirements. I can't predict or preempt change, it is a wasted effort planning for the unknown and unseen.
Note to self:
- Re-read "Pragmatic Programmer" Chapter 4 - "Good-Enough Software"
"Striving to better, oft we mar what's well." - King Lear 1.4
Cheers,
Ted ;)
You should have read RandsInRepose Article on Incrementalists & Completionists. Interesting Correlation...
http://www.randsinrepose.com/archives/2003/08/05/incrementalists_completionists.html
Craig,
I guess you could say I am a Completionist who has discovered that solving the problem "The Right Way" is detrimental to other aspects of a project.
Am I an immerging Incrementalist? Who knows. I just know I am spend to much time doing things "The Right Way", when "Good Enough" is a much more realistic and tangible target.
Nice article. Thanks for the link!
Cheers,
Ted ;)
"good enough" is similar to the extreme programming paradigm. Basically, do what you have to do, but nothing more. Don't bother catering for the future, because it's generally a waste of time, requirements continually change. It also believes future-proofing is a joke, which is true.
Generally I agree with this, but going the extra effort to make it extensible, especially when you know of things that will be implemented later, is the better option.
Steven :: http://requiem.net.au
I wanted to pick up several points.
First one is having the manager saying in passing that an additional requirement needs to be met.
At this point, you know your requirements process is crap, and needs very serious work. The manager should have known that would be needed, and it should have been in the document, before you ever saw it. Having this happen is a definition of a dysfunctional process.
If your process is missing important requirements, forget about even getting to "good enough", you don't really know what your customer wants or expects.
Ideal, now, is another subjective thing. If the customer doesn't agree about what ideal is, you have at best wasted your time. And this gets back to a requirements process that takes enough time and care to capture the real business processes and practices. (What they actually do, as opposed to an all-too-short, all-too-sanitized, PC version of what they say they do.)
It's hard to take too much time on design, particularly in a "grab it and start coding" shop mentality. It's hard to get too much customer input, especially since they often don't want to be bothered figuring out what they want. "Oh, you just put something together, and we'll tell you if it's allright." AKA, "why we're late and over budget."
In other words, if you've got mid-course requirements being added, you haven't a hope of getting to what the customer thinks is ideal. You just don't know enough about what they really need.
The Right Way is, to me, not the same as ideal. Doing things the right way is orthogonal, and is a defense against "throw it out and start over". The Right Way goes to pure design, as opposed to functionality, program flow, features, etc.
The Right Way is avoiding built-in limitations that usually happen when someone isn't thinking imaginatively enough. "We'll never need more than 64 bits for this." "We'll never need that many records, just read the whole thing into memory." "We don't need the date object to be able to do that." And then coding so as to preclude the possibility without a total rewrite.
Yes in my example the manager clearly made a mistake in the development process. Although software development is a human endevor and humans make mistakes. I demand hard requirements but I accept that change will occur and mistakes will happen.
When I wrote about "Good Enough" and "Ideal" these were intended as my judgement on internal decisions on developing a project, not regarding external judgements from a customer. This was me looking at me and dertermining where I waste time on a project, nothing more. I can be subjective with myself. ;)
I am from a different camp altogether and I just see things differently. The customer is right and if requirements need to adapt to a market change or a new feature is required mid-dev, well, sometimes you have to do it. A process that addresses a customer's needs is a good process and ignoring the customer or market is no way to do buisiness.
Take a look at http://agilemanifesto.org/ and the http://www.pragmaticprogrammer.com I find them invaluable especially in dealing with the human element.
Sorry that I wasn't more clear on the intent.Cheers and thanks for the comments.
Ted ;)