This article is part of an ongoing series. See the blog entry Delivering Your Enterprise: The ilities for an overall discussion.
We’ve all been on projects where management stood up and announced some variation of “The project is running late – we don’t have time to do any more design, so just start coding.” The junior members of the team get excited (“About time – coding!”), while the battle-scarred veterans roll their eyes, mentally groan, and update their resumes once they get back to their desks. The veterans expect things to get messy based on past experience and they’re probably right. Frankly, for consultants it’s more problematic, since in the worst case the consultants get fired and blamed for something they may (may!) not have had any control over, and in the best case the consultants don’t look good and have a mess to clean up. See, for instance, the failure of the State of Oregon and Oracle to provide a health insurance site here.
To be honest, I’ve been one of the management dorks that had to deliver a variation on this theme. As I’ve gained experience over the years, however, I’ve learned how to manage this more towards inconvenience than mess. So how do you interpret what’s been said, and what action do you take? And what does this have to do with our topics of Adaptability and Maintainability?
At various times in my career I’ve interpreted these “just do it” pronouncements differently, depending on my role and the state of the project. As a developer, more than once I felt this ready, fire, aim approach was an affront to the beauty and elegance of the code I had so carefully constructed (or planned to construct). As a manager, I appreciated the importance of delivering the project, especially if failure meant losing our jobs at the startup. Elegant code without delivery is useless. So I’ve come to interpret the “just do it” directive to mean find an expedient design, make it work, and we’ll rework the solution later as we need increased functionality. It’s a pragmatic approach.
To get back to our theme, we’re really affecting the Adaptability and Maintainability of our delivery.
- Adaptability – The ability to adapt the software system to new or revised requirements with minimal effort. This may involve requirements that were never remotely envisioned when the software was first developed.
- Maintainability – In addition to Adaptability, the ability to find, fix, and potentially prevent defects or their cause. This also incorporates Supportability and Serviceability. Check out these articles on Maintainability in general and Software Maintenance specifically for a good overview.
The reaction of the veteran developers to “just do it” is really a recognition that the Adaptability of the software will be reduced and that some level of rework will be required to achieve an acceptable level of Maintainability. Rework is always more expensive than doing the preparation up front. It’s just like painting a house.You can skip preparing the surface, and the painting time and effort will be the same with or without the preparation. Initially you save the preparation time. However, without preparation the house is likely to fail (need painting) sooner than it would have with proper preparation, and over the long run more paint and effort will be required to address that failure. Management (the homeowner) tries then to balance these costs with lost opportunity and other cost factors.
So in delivering your enterprise, what do you need to consider to get good Adaptability and Maintainability?
- Architecture – Is your system divided into discrete subsystems, each with a clear and definite purpose? Are there well-defined interfaces between the subsystems? Does your system follow programming in the large patterns such as MVC (Model View Controller)? Is business logic isolated in one spot, distributed haphazardly across multiple subsystems, or worse yet, copy-pasted in multiple places? If someone else needed the same functionality contained in one of your subsystems, how difficult would it be for them to reuse the code without your help? Is the system documented, and is that document kept current as the system changes? Or do you pray frequently that your key (architect, developer, DB admin – pick one) never takes up a hazardous sport like rattlesnake wrangling, because without them the project would fold?
- Configuration – If your organization changes to a different database implementation tomorrow, would it take you 5 minutes or 5 months to change your system? Are configuration details embedded in code or in a configuration file? What happens if that file is deleted? Can the system be clustered (correctly)? Do you have to take the entire system down to do a software update? If load increases dramatically, can you double the number of processes writing to the database or providing web services, without redesign?
- Robust code – Do your teams follow coding standards? Do you hold code reviews, and does the team understand why? Are design patterns used? Do your developers document common idioms and approaches for your subsystems? What is the common strategy for handling errors and exceptions? Is your code brittle, requiring more and more effort to fix what should be simple problems? How long does it take for a new developer to become productive? Does your software development process encourage and emphasize quality?
- Testing – Do your teams test everything from individual code components through subsystems? Is testing part of an automated build system? Do you use test-driven development? If a defect is found, what do your developers fix first, the tests or the code? Do your teams have test plans and actually follow them? Is your code tightly coupled, making it difficult to test?
- Measurement – Can you instantly tell your management the percentage of test code coverage and where improvement is currently focused? How long does it take to fix a serious defect? Are code complexity measurements part of your automated build? What is the arrival rate for new defects versus defect closure? Are critical subsystems monitored in production, so that you know about capacity or other issues before the system crashes?
The point of all these questions is three-fold:
- The questions are a lot less about technology and a lot more about people and processes.
- Because these questions are really about how your organization works (or how dysfunctional it is), you can’t take the “just do it” approach to come up with answers.
- You won’t get it right the first time.
So turn off your computer, phone, and laptop, find a quiet place, and just do it. Think.