In this world of cost cutting and temporary resourcing, the importance of looking at the long term strategy when defining a solution’s design can get lost with the pressures of implementation deadlines. How many times has a team been asked to shorten their design time in order to “get on” with the development effort and get something out to the market? As a designer, how many times have you been told to worry about the fine grain details later – aka when we work on the low level designs for the developers?
Take an honest look at your project resources. During requirements gathering we have; technical leads, business analysts, product owners, architects, project managers, and many others reviewing every single word in the requirements. However, when the requirements are done, the team drops to a few technical leads and possibly some architects trying to push out a design with enough information to get the development effort started. Who is inspecting every flow, component, and rule in the design? Who is making sure that the design meets the basics of solid design fundamentals?
A respected VP and Director I know once told me that there are few things that are more important than a great design to make great solutions. The analogy that was given is roughly repeated below:
“A good design is like a blueprint for a house. Many designers can design a three bedroom house since the same blueprints usually work with a few tweaks on similar houses. They know how to put in the plumbing, build a standard foundation, and where to put the doors. However, I assert that the blueprint must be evaluated against the long term needs for the final solution. If the blueprint is for a three bedroom single story house, they you should never expect that house to turn into a five story apartment just for the desire of making it one in the future.”
I’m a big fan of Agile and Iterative development methodologies. These methodologies have moved development to greater flexibility and delivery capabilities in many ways. However there is a catch…as there is usually a catch in all good things. If there is not a blueprint for the final condition (or at least a review that ensures that the final condition can be supported) then no number of iterations or sprints will ever be enough to reach the final goal.
Let’s go back to the blueprint analogy and explore some of the detailed examples that came out from the analogy above.
Let’s say that the requirements from the new property owner describes a single story building that will support three people and will provide those people security from robbers and weather conditions. Those owners know that at a later date they will be asking for something that will house 200 people, provide a gated security system, and contains a pool and tennis court. However, since they really just want to get that single story house out there as soon as possible and start getting revenue from renters, they tell everyone that they will deal with those larger requirements “later.”
The designers look at the requirements and start building a blueprint for a house that has a couple of bathrooms, a single-story-rated foundation, and standard deadbolt locks on the door. Everyone likes the simple design, so the development teams start implementation and celebrate the completion of the single story house with great fanfare. The owners have renters move in and praise everyone for the modest income they are seeing.
Later, the owners meet with the designers and ask them to add few more stories and 20 more apartments to the building so that they can get more tenants into the building and make some more money on an already winning income source. After some tears and anger – the designers agree to give the owners what they want. The designers decide that they will need to kick out the current tenants so that they can build a stronger foundation. Then they realize they need to change the entire security model to include key card access and large gates to keep the strangers out and the tenants secure. Finally, they are surprised to find that the city’s current residential sewer line will never support the new needs, so they design a new commercial-level sewer system for the property.
The construction crews that worked on the single story house are livid that they have to redo so much of their original work. However, at least it is paying work! They don’t have a lot of time to completely rebuild the foundation, so they decide that maybe they’ll just add some more concrete and hope that it will hold the weight. They deliver an updated building and great fanfare is made of the new delivery. Then the city inspectors are sent in.
The city inspectors find that the foundation is sinking under the weight of the new floors. The sewer line could not be ran to the area because it was in a residential zone and commercial lines cannot be ran into the property unless they spend millions on rezoning and new city infrastructure. Finally, after much finger pointing and lost money, the effort is shut down due to permit violations, zoning violations, and budget overruns.
So why spend so much time on the analogy above? Because, this cycle is seen over and over again in the software design process that most teams work within. How many times have we implemented software only to find that the initial authentication mechanisms were not adequate and we needed to implement complex single sign-on features using expensive third-party systems? How many times have we seen software that was not thread safe and highly scalable because the development team thought they were building a 1 TPS solution vs. a 1,000 TPS solution? For the operations folks – how many times has a team asked you to place a piece of software on your low transaction network only to find out that it was really supposed to be running across a highly redundant and highly scalable network?
How do we keep this from happening?
- Project owners need to insist that the teams (including themselves) do not get into a cycle of “we’ll figure out that complex feature later.”
- Designers need to understand the end state of their designs and implement solutions that allow for the migration from starting iterations into their final conditions without major foundation rework and redesign.
- Finance needs to ensure that they provide budget for efforts by giving the design team the resources and budget to ensure that they can understand and design for the end-point solution.
- Reward those teams that save time, rework, and funds by having a solid plan of how to get from state A to state G.
- Re-train those that feel that the measure of a good design is how many fancy window coverings, cool colors of walls and carpet, and number of awesome garden tubs that they can put into that single story house instead focusing on the long term goals.
The ideas above sound easy to do. However, I am always amazed on the number of stories I hear at gatherings for development managers, designers, and technical leads across industries where they same comment is made over and over: “If I would have only known that they wanted it to me like that then I would have done everything differently.” That said, over-engineering is also another challenge for good designs – but I will cover than in future posts.
In the end, give your design teams the tools and information that they need to create a design that meets the true needs of the solution and they will amaze you with the results. Trust me – a few extra weeks in design can save thousands in development re-work.