In my last post, I talked about one of the 3 Common Software Design and Development Mistakes That Cause Teams to Fail, which is also the title of my e-book. In this post, we will expand on that topic to concentrate on why neglecting to design the code may be sabotaging your work, even if you’re not yet aware of it.
How Designing the Code Makes Us Agile
The vast majority of software development teams follow some form of Agile framework. Using Scrum as our example, we’ll highlight a common sequence of activities.
First, we have Backlog Refinement/Grooming or some sort of feature prioritization meeting based on delivering the greatest value to the business.
Next, we have a Sprint Planning meeting where developers are assigned to (or volunteer to) implement the prioritized User Stories.
Then, we execute the 1-week, 2-week, or sometimes 3-week Sprints, building the prioritized features defined by the User Stories.
Finally, we have a Sprint Review/Demo followed by a Sprint Retrospective meeting. This cycle (or similar sequence) repeats, sound familiar?
This is all well and good, but where does designing the code fit in to ensure we are “maximizing the amount of work not done” from the Agile Manifesto Principle 10?
Answer: It is on us (the software developers) to inject this design effort into our Agile process as a User Story or Task. This is not a visible feature to the business, nor is it an activity that most Scrum Masters/Project Managers will insist on us doing. However, this is an engineering activity that will have negative long-term and widespread consequences if it is not done.
The Cost of Not Designing the Code
Without designing the code before implementation, we cannot produce the level of reuse, encapsulation, and loose coupling that is needed to guarantee our software systems remain maintainable. Skipping this step typically results in us having to perpetually refactor our code whenever a new feature is requested because we didn’t produce a sustainable design in the first place.
This problem compounds over time, yielding ever-increasing difficulty in terms of effort (and bugs) with each new release/feature. To make matters worse, the overall financial cost (and time cost) of supporting the software system continuously increases.
Our job as software engineers is to design and build loosely coupled, highly cohesive, logically consistent, service-oriented software systems that are extensible, testable, and maintainable.
In order for us to achieve this, we must insist on designing the code as part of the software development process. It should never be skipped. When time is tight and deadlines are hard to hit, this single activity can mean the difference between being done on schedule or missing deadlines by a mile.
Using proper techniques to design the code makes the implementation (and testing) easier and more predictable. It also provides a mechanism to structure the code, so it does not get more difficult to enhance over time.
A Hard-Core Engineering Activity
Designing the code is sometimes referred to as “detailed design.” This is a hard-core engineering activity that requires a detailed analysis of the business requirements for the feature or set of features.
As mentioned in a previous post, this is accomplished by leveraging the well-known SOLID Principles and being aware of certain design naming smells that hint at an unripe design.
This work takes the form of interfaces (service contracts), data structures (data contracts or DTOs), class hierarchies, and design patterns. This activity should be committed to source control and code review prior to implementation starting. The combination produces clear guidance to the implementing developer and serves as a form of documentation when sequence diagrams are included.
Don’t Take the Risk; Download Our E-Book
Why take a chance by not designing the code and risking negative impacts on your project (and your career)? Performing detailed design just before implementation is by far the best way to combat the “death march” and avoid perpetual refactoring that yields a hard-to-support, buggy software system.
To learn more about the other two common design and development mistakes (and how to avoid them), download my e-book!