Building a new application is exciting and scary. But it is also challenging.

So many things need to be built, where do you start? You imagine all the cool features and anticipate future gotchas, but do you accommodate for them now?

This is what makes greenfield development one of the most challenging experiences in a developer’s career. Fighting back the urge to build it all now.

But you shouldn’t. And hopefully after reading this post, you won’t.

The Last Responsible Moment

The key word in the last responsible moment is the word responsible. Don’t read the phrase and think “defer everything to the end!”

That is not what it means.

What it does mean is to build what you need right now. Don’t build software for anticipated problems.

Build software that solves the problems you have.

Defer important decisions until your application is built up a little bit. You will have a clearer understanding of the implemented architecture as well as better comprehension of what your customers want. You will never know less than you do right now.

Let’s take an example.

You are building a forum for boat repairs, Holey Ship. You don’t have anything built yet, but you know from prior experiences that people are going to abuse your site. They are going to come in, heckle, offer bad advice, and bring the morale of the community down.

So you know you’re going to have to build a user banning mechanism to prevent that from happening.

You start building out your banning mechanism, and it turns out to be more difficult than you thought (pro tip: it ALWAYS is). You pour tons of time into figuring out how to ban a user only to step back and realize that you don’t have a way to ADD users. You don’t even have a way for users to post on the forum!

While this might be an example of poor prioritization, it’s also an example of solving a problem you don’t have.

Image by StartupStockPhotos from Pixabay

Solve The Business Problem First

Put your priorities into solving the business problem. For Holey Ship, we must add users and allow them to post messages.

The last responsible moment before solving the primary business problem is day 1.

While banning users certainly is a feature you might need at some point, there are many other things that need to be done beforehand.

• Adding a new user to the system
• Allowing users to post new topics
• Allowing users to comment on topics
• Setting up moderators
• Categorizing topics into meta groups
• Ranking popular topics for visibility

The list goes on and on. Remember, at the beginning you need to focus on providing business value - not moderating.

Nothing else matters until you solve the business problem.

Again, finding the last responsible moment comes down to an exercise in priority. If you know how to prioritize your features based on the needs of the customer, then knowing what to defer to a later time becomes simple.

Image by Boskampi from Pixabay

Just Hardcode it

I published an article in 2019 that took an extreme stance on hardcoding. In it, I said you should hardcode everything until you NEED it to be configurable.

I stand by this mantra. And it goes well with the whole last responsible moment thing.

With Holey Ship, what if everyone on our forum got along great? Nobody heckled, it was just a community of genuinely nice, hardworking people.

If you had spent all that time building the banning mechanism, consider that time wasted. But if you had hardcoded around that area, congratulations - you spent the minimum amount of time on a problem you did not have.

If you set your focus on the business problem and hardcode everything else (within reason), your time to market will be significantly shorter AND you won’t build anything you don’t need.

Image by Igor Ovsyannykov from Pixabay

Finding the Last Responsible Moment

So how long can you defer complexity without being irresponsible?

Next time you determine when to build a new feature, ask yourself the following questions:

• What problem does this solve?
• Do I NEED to solve this right now?
• Are all the pieces necessary to support this feature already built?
• When do I need this by?
• How long will it take to build?
• What are the unknowns?

These questions serve as a little responsibility litmus test. If most of these answers feel shaky or undecided, it might not be time to build the feature.

If you have strong, confident answers, maybe it’s time to pull the trigger and start building.

Remember, the longer you defer (responsibly), the more you’ll know and the stronger your solution will be.

Conclusion

When building software, you don’t want to jump into any irreversible decisions prematurely. With agile development, your plans will likely change a little bit every sprint.

Let your application take shape. Get a better understanding for what you’ve already built. When building a house, you don’t start with the handles on the cabinets. First you pour the foundation, then you frame it, then you add the cabinets, install the floors, paint the walls, THEN you put on the handles.

Making an unnecessary decision early on in software is like picking out cabinet handles to match the tile when there is no tile. Get it in first, then decide.

Tamper back the burning desire to have a fully designed application day one. It’s not going to be built that way, guaranteed.

Finding that last responsible moment will help you build only what is necessary exactly when it’s needed.