Write Software that Evolves
In software development we can easily get trapped in analysis paralysis. Having the foresight to make all the correct decisions is hard. We make hundreds, if not thousands of decisions during the lifetime of our software. You’ll likely get something wrong. Instead of trying to get every minutia correct before starting a project, we should aim to write software that can evolve.
Continuous Minimum Viable Product Development
One approach in combatting the constant changing of requirements is to strive for a continual minimum viable product (MVP). An MVP is the most basic version of a feature or application that satisfies a need. For example, let’s say our client wants the ability to view some information. We may only design a page with a table that holds the data (We wouldn’t add additional features like filtering or graphs). Notice how I said continuous. This process shouldn’t end after the application/feature is released. Keeping improvements incremental and small allows us to be flexible in our requirements. Do no more or less than what’s being asked.
Lazy Evaluation
“I’m sure the user would need this feature. It’s easy, I’ll just add it”
This kind of thinking is killer to flexible software. First, every line of code has a cost. Not only are there time, money, and energy in initially writing the code, but also the maintenance and surface area for bugs creates its own cost. Second, the feature added could never be used by the user or just wrong! Best scenario this doubles the amount of work adding the feature.
Instead of eagerly evaluating requirements, flexible software works best through lazy evaluation. Wait for the client/stake-holder/user to ask for a feature before implementing it (even on improvements you know they’ll ask for). Lazy evaluation has a few benefits. It reduces adding features the user won’t use–they asked for it. It also allows us to understand what the user is really asking for. Instead of creating something then asking, “is this what you want?” we’re able to get up-front the ideal process.
Summary
Instead of picking a target a firing–hoping we hit something. Combining continuous MVP and lazy evaluation keeps us agile. It allows firing in a direction and incrementally changing course as the target moves. Of course, do your homework and gather requirements beforehand, but aim for software that can evolve over time instead of trying to get it right from the start.
Photo by Jamie Street on Unsplash
Top comments (3)
Great article Dylan. I am a huge fan of iterative development and only building things that provide value. Don't build it if it doesn't provide value to the user or the overall system.
What a good article! I love the concept of MVP, I use it a lot for my personal projects.
Loved the article! I learned about the concept of MVP a couple of years ago in a Scrum course and immediately fell in love with it. I build most of my projects that way since then.