Go ahead, say infrastructure one more time….

If you read this blog you are probably interested in agile.

Let’s recap what agile means: agile is a mindset for product development, focusing on fast delivery of business value and about getting the necessary feedback to make the relevant changes that enhance the delivery of more business value.

 But how fast is fast? Is a 6 month releasing fast enough? No.

How about 1-month release? Better, but probably not enough.
How about two weeks? Much better, but still, I believe you can do even better than that.
People say to me: “Less than two weeks? Have you lost it completely?
It is often impossible to deliver products that fast”, my regular follow up question is:

Why do you think it is impossible to deliver features in less than two weeks?

One of the most common answers to that is because in order to build a specific feature we need to develop the infrastructure code for that feature, and until we have the infrastructure to support the business logic code we cannot complete it (the word waterfall echoes in my mind….)

People in our industry are trained and educated to think that way, although, if I may say so, this way of thinking is wrong. I am not claiming that there should not be infrastructure code (or common code) in our system, quite the opposite, DRY (don’t repeat yourself) is a crucial design principle for software development. But that does not mean you have to build everything in advance, infra code should evolve side by side with the business logic, it should reflect the needs of the system and be done just in time. Still, sounds vague? Let’s see an example.

We have zero code, we are starting a new product. One of the features is user management, meaning we need to be able to create/delete/update user objects. The classic thinking would go like this:

  • Let’s plan exactly what the user object will look like, which attribute will it have, what relationships with other models in the system it needs.
  • Let’s create a data scheme and a DB for this object and its relationship.
  • Let’s make sure that we are choosing the right DB.
  • Let’s create an infra layer to support all of these operations (and some more we will probably need later) on the DB.
  • Let’s make sure all validations are covered.
  • Let’s write the business logic code for all of these actions.
  • Finally, it’s time to build the UI.

Well, this will probably take a lot of time to complete. Which means slow feedback, this often creates mountains of code that no one actually uses (since we built the infra code before using it), it delays testing, and adds many more “perks”.

How about the following alternative:

  • Let’s quickly define the minimum set of attributes we know that are required for a user.
  • Let’s choose a DB that makes sense right now (perhaps one that we already are familiar with)
  • Let’s create a data access layer that is completely decoupled from the DB implementation. Which we can quickly replace if needed and implement one feature, say create a user.
  • Let’s implement the minimum business logic and validations for that, for example, making sure the username is unique.
  • Let’s build a minimalist UI to support this basic action.

 So, it is possible to create a feature quickly, and even to get some additional benefits:

  • We quickly validate the basic design assumption we made.
  • We know that our code is exactly what we need,
  • We are able to show this to the business stakeholders and get feedback.

Please, before you tell me that it can’t be done in two weeks, make sure you consider all alternatives. There is more than one way to do anything

May the force be with you.


Share on print
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on email