Roadmap A typical roadmap is something which gives a chosen possible path with alternate routes, options and milestones. But these alternatives and options stop at the map level and do not move into product roadmaps in the industries. It is very common to see product roadmaps published with milestones and when to expect them but all of them are linear. It is not a roadmap, it is just the road ahead which is more or less static. Responding to change is possible only when you have a roadmap, else every problem that comes in the way puts us in a hardship as we were not prepared to respond with alternatives.

How do we come up with a roadmap for software projects? Just like maps the requirements have to be visually triaged. We need to collect them at granular level such that it can be captured recorded in one or two sentences that can be written in bold on an index card. These granular requirements are popularly called as stories which represent an action of an end user or the ability of the system.

Once we collect most of the possible actions and abilities then we lay them all together on a large table or put it up on a wall to see them all at one glance. This helps us to triage quickly and discard duplicate ones and add some more if they were found to be missing. Once we have come up with an initial list then we collect the cards as per the priorities and arrange them linearly. If a requirement can be done in parallel then a parallel stream is introduced. In this manner we will be able to have a visual data on what are the dependencies and how much can be done in parallel.

We should play around the sequence and parallel streams to come up with multiple options for milestones and these multiple options together constitute a roadmap. Every few months it is better to revisit to the roadmap as software projects are always a moving target. This is nothing but the release planning meeting mentioned at XP website. We have to be aware of the options and not just rely on the first release plan that we have created, if we rely only on the first draft then it is just the road ahead; we will achieve all the milestones as per the plan but it may mostly lead to a not so desired location.

Last mile problem is ubiquitous. Most of the developers think that the deployment or production readiness is not their cup of tea and stay focussed at getting their output for an input given according to the specification. Usually the last week of the release is chaotic with many dry runs and hot fixes. It is so easy to avoid the last mile problem yet so many people avoid those ways. What if the inertia of setting up build scripts & configuration are taken away? Will it be easier for developers to build ship ready applications?

Spring Boot and Gradle is a great combo to get started in the morning and ship a prototype in the evening. Much of the inertia that is present in writing ant scritps and configuring a spring application is blown away by making very simple entries. Here are some examples that makes the life of a developer easy by eliminating the complexity involved in project setup and deployments.

gradle wrapper – This creates a wrapper script for gradle such that only the first developer who sets the project needs to install or have gradle on their machine. From the next developer onwards who checks out the code, they can start using gradle through gradlew script. No installations required except a JDK and a VCS.

gradle build – If the Spring Boot’s starter web is used then this creates a uber jar with an embedded tomcat and all the library dependencies. All we need to deploy is run ‘java -jar myapp.jar’ in the required locations. Configurations can be overridden either through command line arguments or through external property files.

gradle eclipse or gradle idea – Helps in setting up the project in IDE. Once imported in IDE running a web app in debug mode is just right click, debug application on the main class.

gradle bootRun – Command line way to quickly bring up the application and test it as a whole.

Building a 12 factor app with gradle and spring-boot is very easy and uses less effort. Get the project setup with this and pair it up with a continuous delivery tool, you get a ‘Ship Ready’ application right from the first day of development.

The first time I created an email account, I subscribed for newsletters, turned notifications on all the accounts I created in the net and was happy to spend time reading the emails I received, still the number of emails were manageable. Fast forward to now, emails have grown to be a necessary evil. Lots of people whom I meet are finding it difficult to handle the volume of emails they receive. Since it is easy to create digital copies and apparently costs nothing to include another person in the email for Just FYI, people are given an information overload through emails. It is not uncommon to hear people saying they have 10,ooo+ unread emails in their mailbox.


Here are some simple rules I created so that my Inbox shows ‘Inbox (0)’ at regular intervals. It also helps me to quickly act on only the important emails when I check through my phone.

Newsletter subscriptions – Most of the sites where we use our email id, will by default have the newsletter option checked, we should make sure to uncheck it before creating new accounts. In case we accidentally subscribe to one it will still carry an unsubscribe link. Some email systems do not unsubscribe well, ruthlessly mark them as spam. It is our inbox and we have every right to deny entry to it.

Forums – These have to be filtered into a bulk folder like ‘forum/abc’, ‘forum/xyz’ depending on the no of forums and frequently read ones.

Notifications – Twitter, facebook, linkedin and many other accounts have email notifications, if we have the habit of using those accounts directly and frequently then we do not need the email notifications to be turned on.

Projects and distribution list – We will be part of the distribution lists of projects and business units, filter those into appropriate ones like the ones created for forums.

Finance – Create a filter for all financial transactions like payslips, transaction advices, statements. It should be a one stop folder to view the mails for all the transactions.

CC – The mails which we are CCed are an FYI which do not need any action, people also have a tendency to just add another person to CC; which we can read the subject line later and choose to read or drop.

Bookmarking – Time to time we get interesting links and forwards, instead of leaving them in the inbox to read later use a site that is helpful for bookmarking so that you can read them later.

With the above filter we can drastically reduce the number of emails that arrive at the inbox and we will be able to manage the lesser number of emails. The filters should be such that only the mails which are addressed to us in the ‘To’ field should be delivered in the inbox. Spend time at a manageable frequency to glance through the filters to triage them. Maintenance of the inbox is not an one time act, it is an ongoing activity

“Image courtesy of Patchareeya99 /”.