Building a Development Process - Part 1: Design First

By on
Delivering high quality code that fulfills every client requirement is one of the most vital aspects of a software consulting company’s success. The technology industry is plagued with accusations of missing functionality, unmaintainable code and a lack of extensibility. The adoption and business-side buy-in of agile methodologies provides a remedy for many of these problems, but there are a lot of things that agile methodologies do not, nor purport to, address.

While upfront design is often overlooked and undervalued by a development team, focusing on design in the beginning of a development process will provide a homogenous solution, increase efficiency during coding and distribute knowledge during problem solving.

If you're like most software teams, you have coding and architecture standards, you try to make use of design patterns and you recognize the problem of code debt on long, evolving projects. We found that when you neglect the upfront design session, you tend to get solutions that don't conform to the code style of the project, or the team. As a result, you are often not reusing existing code, conforming to the design patterns, and potentially increasing the chance of creating regression bugs. In addition, any intuition a future developer may have about how and where a problem was solved, based on the rest of the code, could be completely wrong. For example, if you are designing a site using an MVC platform, and all of your functionality uses form POSTs and location changing GETs, it would probably be the wrong choice to add a new method to the controller that takes an Ajax request and doesn’t alter the URL. The next person to develop on that project could miss the design caveat and make breaking changes, or, if they need to make a change to that feature, it would take more time to figure out how it was implemented.

Another issue created when upfront design is ignored, is the use of the 'quick fix'. While we have all implemented a ‘quick fix’ from time-to-time, the chronic use of short-term hacks can result in code debt, unexpected behavior and failure of regression tests when updating or refactoring the code. It can also make future changes take significantly longer - hurting your reputation and costing your client extra.

Recently, we encountered a problem where it appeared that our RESTful architecture would have to be violated due to the requirements from the business team. Our users wanted to search and sort a list of records, and then navigate through that data in based on how it looked in the table after the search. The problem was that the changes users could make to the records while navigating through them could (and often did) alter whether or not the record would still qualify for the search, making things disappear from the list unexpectedly. After a long internal discussion, we decided to treat the results of the search/sort as a static ordered list of records, defined when the user begins navigating through the data, and access that object in a RESTful way. Without that upfront discussion, our solution would have been to cram in a quick fix, resulting in bloated, complex, strongly coupled controllers, and future changes would undoubtedly have failed regression tests.

Ignoring upfront design and throwing architecture discussions and design solutions to the wayside to start speed-coding immediately can seem attractive, especially when a client needs software quickly. As developers and consultants, however, we should recognize that a few hours at a whiteboard to comb through design details and different solutions are not wasted. As we’ve experienced many times, passing over real problems and assuming the answer is self-evident creates a recipe for disaster. Design strategy takes discussion, hard problems take time to solve and a variety of viewpoints better inform solutions.

Forcing your team to adopt the discipline of ‘design first’ is absolutely worth it. It fosters an open environment, knowledge transfer, complete and a distributed understanding of the problem and solution and a less 'hacky' solution that will be easy to alter and extend in the future.