First, my apologies for skipping more than an entire year. I knew it had been a while, but I hadn’t realized my last post was in December of 2014. My resolution for 2016 is to be more regular.
Most developers have a habit of delivering a lot of code at one time. In many ways the world of Java encourages this and helps developers create habits that are hard to overcome. Even a simple application requires several steps and files to render something useful, especially if you want to follow best practices with interfaces and resources. The result is that making anything work takes a fair bit of overhead. Nobody likes doing all that work and having a very little to show for it.
I’ve experienced this myself. When I add a page to an application my preference is simply to make sure I can navigate to and from the page first. Then I can start putting in the functionality. I can add functionality in small steps with full regression testing to ensure the additions don’t break working code. But I am not just tempted to cut corners, I often give in (although I’m usually reminded why I prefer to go small almost immediately).
There’s more involved, though. My current project is not fully Agile, and our CIO had asked that we stop making updates during a critical season. This meant that our end users overloaded what was intended to be the “last” release before that critical season began. (Naturally, this overloaded release was the worst we’ve ever had.) When end users are concerned about when the following release will happen they naturally want lots of functionality included in the upcoming release.
For these reasons and more there are pressures to release code in big-bang releases. But the biggest reason of all is it isn’t always easy to see how you can make a release smaller. This is an art and one that you need to cultivate in your team members.
As an obvious example, our system is a replacement for a completely manual process. We aren’t replacing any existing tech. When the end users were giving us their requirements they had business rules that they wanted our application to enforce. These were complicated rules and sometimes they conflicted. They also significantly increased our time to complete the initial release.
My tongue-in-cheek suggestion for release 1 was to akin to scanning the paperwork into a computer for viewing in PDF form. But in reality I would have recommended a system that replicated the manual process as much as possible. This meant not including the business rules at all. Since the future end-users already knew all the business rules there’s no reason to enforce them from in software, at least not in release 1. This is just one way to reduce the size of the initial release to a manageable size.
But there is much more you can do. Start working with the following exercise: Instead of asking what is necessary to make the system complete, ask yourself what is the minimum value we can add, and what is necessary to add only that. If you make each increment the answer to this question you will have made huge strides in the art of the small.