Four Possible Paths, Eight Possible Outcomes
The graphic below transforms the title of this post into a visual manifestation that can be discussed “rationally” (<— LOL!).
The graphic shows that pursuing any of the four path selections can lead to a “number 2” outcome. It’s just a matter of how much time and money are exhausted before the steaming pile is discovered. D’oh! I hate when that happens.
Obviously, the path to the holy grail is D->1. Simply take whatever info is known about the problem, code up the solution, get paid tons o’ munny, move on to the next problem to be solved, and never look back. Whoo Hoo! I love when that happens.
Categories: technical
product development, project management, software development
Leave a Reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
Perhaps there is a 5th path:
1. Coherent System Concept (what problem? what drivers/challenges? what approach?)
2. Requirements (acceptance criteria at system and subsystem levels)
3. System Test Strategy
4. Design (including system & components: mechanical, electrical, chemical, software, etc.)
5. Development
6. Test (including unit, subsystem, integration, and validation)
People routinely confuse #1 and #2, but they are very different. In a complex system, requirements are not something to be elaborated or experimented with. Requirements state what you know, after you have made your big tradeoffs and mitigated key risks.
Any project that doesn’t have a coherent test strategy and execution has a high likelihood of ending up in the steaming pile
People routinely confuse system design with electromechanical design, leaving software as the poor bastard stepchild, trying to compensate for errors and omissions in the hardware design. System design must be done for the whole system and all technologies, then all technology-specific designs should be done concurrently, under the guidance of the system design.
Charlie
Thanks for your thoughtful input CA. For sure, all of your points apply, but I was trying to operate at a simpler, higher level of abstraction not obscured by details.
How could I add a fifth path to the (bogus BD00) “model” while maintaining the conceptual integrity and consistency of the dorky original? If you can guide me there, I’ll update it and re-hoist it.
No need to change the consistent, conceptually pure original, my friend. Your point is clear. Spaghetti sauce without garlic is not spaghetti sauce, as a development process without system design is not a development process.
I was just asking the question: “Where do the requirements and system design come from?” since I have seem my fair share of imposters for both. And I’m also sure that the observation about testing needs no further justification, since it is self-evident. Or is it?
Ouch 🙂 I think your points about reqs/design sources, development methodology, testing strategy apply to any/all of the 4 (or more?) paths. Those choices, and how they’re executed, certainly “influence” whether outcome number one or two is achieved. But there is no guarantee of anything. For a given problem, a high ceremony process overlayed on path A can fail miserably whereas a minimal, chaotic process typically associated with path D can succeed wildly.
I suppose I can update graphic with “Coherent System Concept”, “System Test Strategy”, etc, components, but I’ll save that for the scrubbed, poopless, book version that will make me rich and anus 🙂
BD00. I was going to make a past/present/future tense joke here. But then I realized that I have no idea about your past or present finances :-}
To build on what Charlie stated, all the boxes above need to be stereotyped “<>”. Although it’s implied with Source Code, the remaining three (plus Charlies additions) can represent either an artifact or an actual thing. Source Code only is the minimum artifact production, but not the minimum number of elements of the process. Whether the concept, design, requirements, etc. are documented or not, they exist. The question, however, is how well communicated and understood are those things not documented outside the code.
‘fraid of that…stereotyped “<<artifact>>”
Great point, Gene. I once wrote that “all systems have an architecture, but some are intentional”, only to find out that Grady Booch had said the same things years before.
[a la Billy Shatner in “Wrath of Khan”] Booooooch!!!! 😉
Sorry, but you guys may be reading too deeply into the intent of the post. It, like most all of BD00’s posts, is intended for entertainment value only.
I suppose I could ferret out all of the process/methodology posts in my 1000+ post portfolio, polish them off, fill in missing details, jettison the ambiguities/inconsistencies, and write the “next big methodology book”. Too much work and it won’t sell many copies outside of my immediate family. Plus, there’s too many methodologies and methodologists roaming the world today.
Of course we are. Like the scorpion in The Crying Game story, it’s in our nature to read too deeply into things 🙂
CA, my finances are in pretty good shape, but not robust enough yet to allow me to retire to Belize and enjoy the sun with my pack of dogs 🙂