Helman’s Laws of Software Development
These ideas are far from revolutionary, but seeing them followed is surprisingly rare. They not only produce better outcomes, but they greatly reduce risks. Helman applies them consistently to deliver value and guide program teams.
1. Avoid Writing Software.
Many talk about not “re-inventing the wheel,” but countless developers waste energy and time needlessly coding commonly available routines. This is not only silly; it consumes precious creative energy that could otherwise be used to build better software.
Starting with the judicious practice of code reuse (from internal and external sources), Helman drives a focus on coding effort which adds unique value to the software.
2. Pick a Process (Any Process).
ISO 9001, CMMI, TSP, Agile, XP, Cowboy Coding, pick your favorite dogma.
For most teams, it matters much less which “methodology” is used than it does to simply standardize on a core set of practices and stick with them.
Helman has a history of making this happen with great results
3. Write Self-documenting Code.
Regardless of programming language, variables can be named and algorithms crafted so that the maintainability of the code is optimized. This kind of code always has fewer defects and is a better match to requirements than “clever” code requiring a rocket scientist to interpret.
Repeat after me: “Clever code is very bad.” This is because (with rare exceptions, like complex mathematical algorithms) if the code is difficult for someone familiar with that language to understand, the original programmer either didn’t understand the requirement, the code is wrong, or both. The implementation and code should be only as complex as is necessary to satisfy the requirement.
“Clever” is not spoken here; simple elegance prevails.
5. Create Frequent Builds.
Even simple web applications require coordination and integration steps to create a functioning system (“build”), and just about any enterprise-level system can be a build nightmare. Defects invariably lurk in the shadows around these build steps, so doing frequent builds allow the team to identify and resolve them early and often.
The alternative is all-nighters at release time when everyone is at their worst, so Helman makes weekly or daily builds part of the project culture.
6. Deliver Frequent Incremental Releases.
Not every build must be released to QA or the customer, but frequent releases have an amazing way of uncovering requirements misunderstandings and detecting bugs earlier (when much cheaper to fix). Again, there’s no stunning insight here; the methodology gurus have been preaching iterative/cyclical/spiral/RAD life cycles for years, but unless it is part of the project culture, it won’t happen.
To reduce project risks and increase product quality, Helman makes frequent releases part of the project schedule and team culture
7. Avoid Writing Software.
Why yes, this IS so important that it needs to be repeated.
Just like spending some time planning can save lots of efffort later, investing some time to figure out how to leverage code someone else wrote (including COTS packages) can save huge amounts of development time, reduce costs and risks, and increase value.
(Takeaway Reminder: Delivering value (not lines of code) is why we get paid.)