The Agility Series — 2— Facing Rigidity
You’re in the software planning meeting. Tensions are high. Developers are trying to avoid wrong estimates. Marketing and operations want results before the market shifts again. Peace is not how you would describe the vibe. Your mind goes back to the early days of software when everyone was upbeat. Now they look beat down. You are thinking, “How did we get here? Where did we go wrong?” If this is you, you are asking the right questions.
Let’s look at one glaring problem that I find in software that causes this issue. Solve this multi-dimensional problem and you can get back to the fun days of software. If you will allow, let me state the cause and then explain.
The Cause
Software is assumed to design itself through the practice of trial-and-error programming.
The Explanation
Let’s break it down.
Agile implementations generally ignore design thinking. The world of software development was encouraged to remove anything that does not directly impact the creation of working software. Turns out, general agile practices implemented more process steps that fundamentally do not impact software development or quality (story points etc.) and dispensed with quality design which does impact the software and its ability to adapt to future changes.
This confusion has grown for over 20 years now. As a result, a whole new generation of software developers typically known as “the programmer” has grown in population. That population gets promotion to Senior Software Engineer. Why? Because they have been programming for more than 7or 10 years. The reality is actual software engineers are systems designers. Designers are not just programmers. Good designers help streamline programming effort.
Let’s go back to those meetings you were having. You probably are working with some sharp programmers that have never been trained in the art of systems development from a business perspective. They don’t know how to model the domain from a behavioral perspective. Your Domain Experts are in the same boat. They have never had to detail their processes in such a way that they could explain the functional aspects of code in a way that affords the development staff the greatest chance of success in delivering not just on time, but on point.
The pressure to perform pushes developers not just to create tech debt, but eventually what we in the industry term as the “Big Ball of Mud”. Deadline-Driven Development takes the front seat. Imagine being required to cut out rooms of a house or other mandatory features so that you can call the home “move-in-ready.” Imagine getting surgery fast because the doctor and nurses skipped the OR prep. You want that house? You want that surgery?
The issue is, the programmer has no idea how to blueprint or prep. They know how to hammer or cut. That is what they know how to do.
I am working on a list of things you will want to think through if you want to transform your culture so that you choose to make adaptable software by design rather than rigid software by accident.
Until then…
