Decouple Your Web Architecture for Robust Java Applications

In the previous chapters, we’ve laid the groundwork on what we want to change in our architecture. The next step is to determine in what order we’ll work on the changes. But this can be a tough task to start.

Prioritize User Stories

If I look in my garage and see a bunch of boxes to go through, it seems overwhelming. How do I know where to start? The same thing occurs with our software rework-lots of work to do. If we try to tackle it all at once, it will overwhelm us. We need to prioritize the work somehow.

Remember, we want to go from this:

To something with separate layers, like this:

Fortunately, we can apply some proven approaches for prioritizing our work! Let’s start with the financial ones. We have a couple of formulas, but the basics are the same for both:

Prioritize by Return on Investment

First is return on investment, or ROI. We calculate the estimated amount of revenue generation or cost savings and divide by how much the feature will cost to put in. The most money for the least amount of development expense wins.

Well, that’s why companies have accountants. And there’s no guarantee that the numbers are completely accurate. We do the best estimation we can.

Prioritize by Weighted Shortest Job First

Next comes weighted shortest job first, or WSJF. Like ROI, we do the money calculation. But the difference in this approach is that the shortest job to finish is the one that generates the most money. It might make more financial sense to get 4 or 5 small revenue-generating features up and running quickly, than one large revenue-generating feature over a long period.

Next, we have the development-focused techniques:

Prioritize by Technical Necessity

One other option we can apply is a technical assessment. Which stories force the biggest rewrite? Which one allows us to put in a better architecture quicker? This also ties in with ROI and WSJF, but from the technical side of things. The longer we live with the poor architecture, the harder it is to put in the features. So those features cost more to implement. It might make more sense to work on the pure architectural items so that all the subsequent stories will be much easier to put in place.

Prioritize by Dependency

In my garage example, some boxes are on top of other boxes. There is a natural dependency. I need to work on the top boxes first and work my way down. Again, this works for our software as well. Certain user stories have things in common. One user story needs to go first to provide the foundation. So we pick the one with the most dependencies, which will clear the way for the other stories to be completed.

In our airline application, we have dependencies in many areas. We can’t change all of this at once, but by carefully ordering our stories, we can build up each of these pieces, a little at a time. The stories we tackle last should be easy to put in place because the groundwork for all these dependencies will be in place.

One important thing to keep in mind is that prioritizations are always fluid. Due to the fluctuating circumstances of the business, important stories today may be less important tomorrow, and vice versa. As developers, we need to be responsive to the change.

Since our goal in this course is to modify the architecture, we will use technical necessity as our prioritization reason. We will be modifying the application to introduce the four user stories discussed earlier:

• As a tour group leader, I want to book a flight of up to 12 people so that they can experience someplace unique.

• As a pilot, I want to capture a minor maintenance issue as soon as I have landed so that it can be fixed quickly.

• As an aircraft mechanic, I want to update a maintenance issue as soon as it has been addressed so the airplane can be considered ready for flight.

• As the accounting manager, I want to see a list of clients with outstanding balances so that I can give them a reminder phone call.

Try It Out For Yourself

Now, based on our diagram above, which user story would you do first?  Think about:

• What technical elements they’ll require.

• What technical elements they have in common.

• What technical elements already exist in the code. 

Once you think you’ve got a solution, check my answer below.

Answer

Since these stories all introduce access to the application via a web front end, we will start by introducing the view layer. Then we will extract the data layer.

Currently, we have an existing reservation class. It also suffers from communicating with the SQLite and Java Swing classes. Since the tour group leader will be adding and modifying reservations, we’ll begin with that story as it touches all the aspects we want to re-architect.

Once we have the reservation class updated properly, we can use that knowledge to introduce a new class to handle the maintenance issues for the other two user stories. And we'll see that obtaining the list of clients with outstanding balances will be simple to refactor into place once the data layer is established.

Let's Recap! 

There are several prioritization strategies:

• Financial:

  • Return on investment (largest revenue generation or cost savings per smallest amount of development money).

  • Weighted shortest job first (get small features up and running quickly).

• Development focused: 

  • Technical necessity. 

  • Dependency between stories.

Now that we know which stories we're going to do first, we're ready to begin refactoring. Before you do, don't forget to take the end-of-part quiz and test your knowledge. Then join me in Part 2 to see examples of how to refactor an application.