There’s a pattern I’ve seen with companies that are starting on a large green-field project that gets them into trouble later on that I wanted to call out because the pitfall is quite subtle.
It’s something I touched on in my presentation last week about Balancing Architecture & Agile at the Agile Practitioners group in Israel but didn’t have as much time to get into.
Agile
You see, at the beginning of these projects, often our users or customers don’t exactly know what they want. Even if you go through some process of doing mock-ups, sometimes users can’t really know what they want until they can interact with working software.
This is one of the advantages of an agile approach that focuses on getting working software in the hands of users very early. It allows us to mitigate the risk of us building the wrong system.
Pitfalls
The mistake here is believing that this needs to be done in a production-ready manner, using all of the super-scalability and highly reliable infrastructural elements in our target deployment environment.
While there is value in building real functionality on top of your production infrastructure to learn more about the challenges in doing that and in that process, refining the API of your platform, baking more capabilities into it, etc, the problem is that you are slowing down the important learning of what system needs to be built.
Decouple those two things.
Build one to throw away.
Sometimes, the way to be most effective is to be somewhat inefficient.
Once you’ve gotten your users to the point that they can point at a piece of working software and say, “Yes – build me that”, then you can go about building it the right way on top of your production platform.
Embracing the Challenges of Technology: "Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow." (Fred Brooks -- The Mythical Man-Month)
Let me go a step further, just to be crystal clear.
Do not unit-test that code. Do not use TDD, DDD, CQRS, Event Sourcing, SOA, etc.
Just get it done.
Architecture
You also want to have a good understanding of the use cases in your system before you make too many big architectural decisions (where that might even be just 1 decision, but you only find out after the fact). Some use cases are architecturally significant – many aren’t. This falls under the “just enough architecture up-front”, but is really very dependent on the experience and skills of the people on your team so I really can’t give you anything more prescriptive.
Of course, there’s another risk around this approach.
Organizational Dysfunction
In some organizations, there isn’t enough of an understanding or appreciation of the difference between production-ready software and a prototype. I think we’ve all been through this at one time or another. If users see “the software” works, we might be forced to deploy the prototype – all our protests for naught.
If this is the environment you’re in, don’t worry about it.
Seriously – don’t.
Growing up
You can explain to a child that fire is hot, and that they will get burned if they stick their hand in it, but all of that is theoretical – it doesn’t really sink in, because they haven’t yet had a visceral experience of “hot”.
If the organization you’re in isn’t that mature yet, they’re going to have to get burned a couple of times until they learn. The only thing you can do as a responsible adult is to *try* to get them started with smaller burns so that they’ll learn the lessons with the minimal amount of pain.
Given that the people doing the learning are higher up the food-chain, you really don’t have much influence. Accept that and move on. If necessary, cover your assets – write an email containing the “meeting minutes” in which you describe the concerns that you raised and that the decision was made against your recommendations – but phrase it gently. Depending on the state of the economy and your network, it might be a good time to start job-hunting.
In closing
I said it before but it bears repeating:
Efficiency is secondary to effectiveness.
You want to make sure your headed in the right direction before putting the pedal to the metal.
Rework is to be accepted and, yes, even embraced.
Via udidahan
