A case against detailed plans


While for now am not as active in the software consulting game. I have been there enough to come across the perils of overrefined plans. This issue primarily has come up as an artefact of how most westernized countries do work, through contracts.

A contract is a binding agreement between two or more persons or parties; especially :one legally enforceable

Now contracts and especially written ones are great, they have certainly played a key role in the formation of the economy as we know it. Yet their traditional use as loss prevention tools doesn’t auger very well with what we now know about software development.

What you find is the client what everything to be developed in written form and in great detail at while at it.

This is a bad idea. In this entry, let’s look at why detailed contract and detailed plans, in general, are a bad idea.

The future will likely turn out differently.

The art of predicting the future has a long and time honoured tradition of being dead wrong. Matt Nauvak has an extensive library of predictions made in the past and how they turned out.

The problem is when we think about the future, we simply imagine what we know today but in an exaggerated format. For example, the client imagines the application will have to handle thousands of query requests from sales managers who are looking to better understand their customers. This feature may be based on another plan to capture user activity within the application.

All this is well and good until we realize nobody wants to login to use the application and we now need to pivot! So there is no data to be showed on the beautiful dashboards to be used by the salespeople. Some time wasted, but still all good, the real problem comes six months later when the client once more wants their dashboard. You remind them you had a meeting and decided to pivot, they, of course, proceed to remind you meeting notes are not binding, contracts are!

I thus urge you, no matter how certain you feel about the project, bake within the agreement the provision things will change.

Decisions should be made at the last responsible moment

My personality registers as INTJ. One of our key strengths is the ability to make decisions quickly, as you already guessed it, this is also a weakness.

Plans are great because you are able to constrain the range of possible options and get everyone focused on one path. Swahili’s have a saying:

Kuishi kwingi kuona mengi

Roughly translated:

To live a long time is to see a lot of things.

This rings true in software. As your product unfolds more information comes to the foreground as assumptions get tested in the crucible of reality.

It would be terrible to ignore your insights because the plan you made one year ago is in contradiction to them.

Plans fail in highly dynamic environment

Homogeneity is great for some types of work. This tends to happen in routine types of businesses. To give an example, imagine the work of building an estate with fifty apartments all of the same design. There will likely be some surprises in the first few houses, but after that, you can make fairly detailed plans to take the remaining houses to completion.

Now imagine a software project, even if you were CTO at a successful startup say Stripe, if you then started your own business say Airbnb, you would still be encountering surprises every day. In fact, even if you stayed at Stripe, new technology say bitcoin, would still keep presenting new and surprising information.

Fighter pilots have a term I particularly like. OODA

Observe Orient Decide Act

The world changes, OODA loop makes sure we don’t stay stuck with our plans which are now irrelevant.

Avoid the trap of elegance

A common misconception is we love our children and that is why we give up so much for them. In reality, we actually love them because of all we have given up for them. Think about the concept of sunk cost fallacy.

Sunk cost fallacy: The idea that a company or organization is more likely to continue with a project if they have already invested a lot of money, time, or effort in it, even when continuing is not the best thing to do

Now, if you have ever been to a proper planning session, you know they can take entire days if not weeks. Once you have put in that kind of time, you generally don’t want to see it all go to waste. Your mind will play all kinds of tricks on you to ensure you stick to it.

Elegance is great, but as Reid Hoffman says:

If you are not embarrassed by the first version of your product, you’ve launched too late.

This is also true of plans if you put too much effort into your plans, its value is now lost.

Look through your own plans? Are any of them excessively detailed?  Talk to me in the comment section below or on my twitter @jchex




The DNA of Agile practices



Some years back, Martin Fowler and Alistar Cockburn adapted the concept of ShuHaRi from Japanese martial arts.

At its core, it’s simply a way to think about learning.

The idea is that a person passes through three stages of gaining knowledge:

  • Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
  • Ha: At this point, the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
  • Ri: Now the student isn’t learning from other people but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

From this lens, you realize the sacred cows of your own agile practice can be criticized.

Is it really necessary to have a daily standup meeting which is physical every day?

Does your Kanban board really need to have all those lanes?

Must all pairs share a keyboard in your XP practice?

In this entry, we will look past the individual features of the specific agile methods and look more broadly at what unites them, what is their DNA?

Frequent delivery

The idea that final products should well, be final is a pervasive one. It’s one thing to read all about the benefits of iteration and quite another to have your boss or client scream at you for presenting a half-baked product.

Thus we build generous timelines to protect us, to allow to do all the work needed to ensure we present the product that is just right. We know when it’s not. There will be hell to pay.

Agile adopts a more evolutionary mindset, it advocates you ship what works, for now, gain feedback and improve on the product.

This is why Scrum, for example, insists on two-week sprints. There is nothing magical about the number, its simply meant to convey you are supposed to ship something, perfection be damned what we need is working software.


You may have noticed this, the speed by which a project is executed is closely related to how well everyone understands what is to be achieved.

Simon Sinek explains the concept quite well.

If you did manage to forgive the audio quality, you got the vibe, people respond to alignment.

You see communication, especially in software development, goes much deeper than sending and receiving of signals. It took me long enough to realize you can be in a meeting speaking where everyone else is only there physically appearing to be listening to you but lost in their own world.

To properly communicate, you must be able to externalize your mental model and have the other person internalize it. This, in my opinion, is best done when you work together on a physical media, say a whiteboard or a shared doc to express what you perceive. This back and forth helps expose any incoherence in your understanding of the situation.



Thus boards and other interactive information radiators in Kanban help the teams build a shared mental model of the work to be done.

Continuous improvement

The primary school I attended had an interesting motto:

Better your best

It has taken me all this time to finally appreciate what it means.

Continuous improvement is the idea there is always something you can improve. It doesn’t matter if you are a beginner or have thirty years of experience.

Integrating this philosophy into your mindset has two advantages.

First, you never settle, your product is always going to be improving. This is in line with the more general truth of impermanence, no matter how fit the product is to its market today, the market will change tomorrow. Thus you must continue to adapt.

Second, you get the validation to ship your product imperfections and all. After all, there will be a chance to improve on it later.

In agile practices, this principle shows up in retrospectives, where the team stands back at the end of an iteration and reviews its work searching for clues on what they could have done better.

If you learn nothing else about agile, learn this three principles.

What do you think is the unifying theme of agile practices?  Talk to me in the comment section below or on my twitter @jchex



Striving for team balance



Recently, I have switched over from leading the software and design team at iHub to a new role at Twiga foods.

Just like iHub, Twiga has a great development team which I am proud to be a part of.

The big difference is that the organization is rapidly growing. In this environment, it has become critical to once more ponder the question, “What makes for a well-composed software team?”.

In this entry, we are going to go through some of my thoughts on what to consider when you have to rapidly scale your team.

Is there a right balance of junior and senior engineers?

I can’t tell you how many CTOs I have met who brag of an all-senior team. Don’t get me wrong, a senior team works much faster, gets higher quality work done. But when everyone is a senior, who is going to do the plumbing work?

Plumbing work is the necessary rote work in development. An example would be building out an email notification feature. Getting it right is simple in principle but time-consuming in practice. This kind of work would bore a senior engineer but present an exciting learning opportunity for someone greener in the field.

Junior engineers also tend to be a bit more amenable and thus more likely to fully buy into your vision.

With that said, you really don’t want a team skewed too much on the junior side. Their lack of experience means they will not see architectural land mines guaranteed to come back to bite you.

A ratio of 4 senior to 1 junior should work fairly well.

Is there someone with domain knowledge?

On paper, I learnt to drive from a driving school, in truth, I actually learnt from my uncle. One of the things he used to say was

You can only be a great driver of your own car, on the others you are at best mediocre

This statement might seem ridiculous, I mean, aren’t the control’s standard for all vehicles?

Yes, they are. But what about the time the car takes to break? Or accelerate? How has performance been fairing since the last service? In reality, you gain some knowledge of the performance of your car, something like its personality over time.

In the same way, a developer who has worked in the banking industry has some knowledge that a developer who has worked in Agri-tech just doesn’t and vice versa. You thus want in your team at least one person who has some tacit knowledge of how your industry works.

Does there exist a level of cognitive diversity?

In the current heydey of gender diversity, it’s easy to think that is all that matters. There is an even greater consideration, how do your people think through problems?

In a homogenous team, everyone comes to the same conclusion all the time. This is great for speed but it also means you lose out on creative ideas which would have possibly been a better fit for the problem at hand.

You also don’t want a team so diverse, no decisions can ever be fully agreed on. In this kinds of situations, all the energy is spent thrashing ideas which would have been better placed executing on any one of them.

Is the team cross-functional?

The most obvious question in agile, yet still worth mentioning. From a corporate level, functional teams are more legible than cross-functional ones. This means there will always be pressure to split up the team to functional roles.

Even developers do this to themselves, why do so many profiles have the tagline “PHP Developer” or “Angular Developer”? It’s because it’s so much easier to define yourself and your team by what you do rather than by what you produce.

Fight this tendency, focus on your outputs, you can better build a team that carries all the skills necessary to get the job done.

Do you have any advice for me as I embrace on this journey? Talk to me in the comment section below or on my twitter @jchex



The problem with big teams



If two are better than one, a small team is better than two then a big team is definitely better than a small one. No?

Intuitively it seems that the more people you have, the better.

For a software team, this is just not true and not because they are mostly introverts.

In the entry, what to consider when growing a software team, I hinted you should consider limiting your team size.

In this entry, I define a big team as one having more than 10 members. These kinds of teams come with their own set of challenges.

Communication over head

Have you ever tried to organize an unscheduled all hands meeting?

Getting schedules to match is almost impossible even with oversight into what is going on in the entire organization.

Now imagine an individual developer trying to get her blockers worked on in a 10+ person team!

What ends up happening is she spends most her time communicating with other people trying to get work done instead of you know, getting the actual work done!

This is not the perfect picture of effectiveness.

Individual effort lags

Maybe it’s because people feel less attached to others in big teams I am not sure. What is certain is less work gets done per person in teams.

It is natural to assume that someone else will do the work. In small teams, this assumption comes into sharp contrast. If you are not doing the work then who is?

Sluggish behaviour is likely to be more quickly noticed by the rest of the team.

As the Poppendiecks say:

Peer pressure is far more effective than the concept of a boss and much more powerful

In big teams, no one has the cranial capacity to keep up with what everyone else is doing so they just assume they are slacking off and do the same themselves.

Collective ownership goes down the drain

Just as there is individual skill, I believe there are also team skills which need to be nurtured.

When teams are large, the production line becomes the most effective way to organize work.

This is fine if your work can be broken down into small sub tasks which can be easily tested for completion.

Software projects are the antithesis of such work. To be successful it’s critical that all team members have a shared mental model of the product they are building and have a clear understanding of its value to the customer.

The negative effects of hand over will get to you before any Taylorian benefits flow.

There is no direct line between team and individual success

We are all the centre of our own universe. If I have pulled off several all nighters on a project (I don’t recommend this) then I want to see myself acknowledged when the product is launched or another similar success event happens.

If my individual effort will never be recognised anyway, then why bother putting in more effort than is expected?

In small teams, what each individual did can be clearly seen in the work output. This makes the work personal and meaningful with the effect that everyone is now more committed to it.

How big are the teams in your own organization? Talk to me in the comment section below or on my twitter @jchex



How to achieve consistent estimates



At the iHub, we work on multiple projects with multiple teams sometimes all at once. The process of software estimation is perilous at best even when there is only one team working on it.

Our situation is even more complex with individual developers serving in multiple teams and sometimes in a team of one!

Getting to consistent estimates across this various scenarios is not easy. In this entry, I will share some of the tips we have found to work in the past.

Find a common denominator

Estimates usually come in two flavours, days or story points. Ideally, estimates should always be in story points from which you derive days of work.

Unfortunately for most people, story points are just not intuitive. This means they make a great tool for establishing the work to be done but not a particularly great one for communicating the same.

Thus to establish consistency in communication, all our estimates are communicated in ideal days.

To be sure, this has come back to bite us once or twice where the client confused ideal days with calendar days but all in all the gains in shared understanding made for a worthwhile trade-off.

Review stories from similar past projects

Hofstadter’s law states:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

Obviously, this is not a physical law, but you would do well to be mindful of it.

Thankfully, well measured past projects cut through our biases and reflect on us the truth.

For example, one of the more successful projects we worked on, our initial estimate was 5 months, as an e-commerce platform we were sure we understood everything related to it. In the end, it took 8 months from the first commit to a fundable version.

In current projects, we keep this hard lesson in mind as we think of the estimates we provide to clients. Particularly if a client wants a similar application, we now know how long it takes to get it done.

By having such a repository of past projects and the time it took to complete it, disparate teams can base their estimates on them and come up with consistent results.

Estimate some stories together

I expect developers to be very good at writing clean code that has a solid architecture with minimal coupling. I am however quite forgiving if they are not exactly masters of the black art of software estimation.

Still, the more estimators you have, the better. Groups will do wonders to the quality of the estimate.

Even if you will need the developers or individual teams to do their own estimates, it still makes sense to have a session where you work on it all together first.

How do you ensure consistent estimates in your organization? Talk to me in the comment section below or on my twitter @jchex



Fostering a culture of team learning



Recently, we were sharing our experiences with my friend. He mentioned a statement his boss used to tell him when he worked at craft silicon.

I would rather hire three average developers than one rockstar developer. Within six months they will have delivered more.

Obviously, this rings true to my team orientated mind.

Yet such delivery does not just happen automatically. In the same way, individuals need to learn, so do teams.

Anita et al describe why some teams are smarter than others

In this entry, I will be looking at what you can do to stimulate learning in your own developer teams.

Break down communication barriers

As companies grow, the amount of paper work grows as well. This is not necessarily a bad thing, it implies the organization is codifying its knowledge thereby reducing rework.

For example, if you are hiring 8 – 10 developers every month it probably makes a lot of sense to have the on boarding process in a document.

The problem comes when communication happens primarily via documents.

The key here is to challenge yourself not to create a policy every time something goes wrong. Policies are only useful when the situation reoccurs many times within the course of your business.

You maybe intimately aware of agile’s face to face communication principle, yet the allure of beautifully detailed dashboard is guaranteed to get to any manager.

Don’t get carried away, there is such a thing as, over collaboration, constant communication also disrupts creative work.

If you do manage to hit the balance between process and communication the next biggest challenge is to ensure the team is kept intact and members are learning each other’s vocabulary

Build whole team responsibility

I find it surprising some people deliberately pigeonhole themselves with meaningless titles; “PHP developer”, “Python developer” etc. Of what use is your language to the business?

Clients care about having their problems solved. This means everyone in the team is a problem solver first then whatever other titles they chose.

In this mindset, everyone owns the outcome, not just the tasks they are working on. This means if as an individual you do everything right but the project still failed, then you also failed!

The more everyone has been involved in everything the more responsibility they will feel towards its success.

Lynda Gratton puts it as:

    working with other people was never more exciting and exhilarating and when you knew deep in your heart that what you were jointly achieving was important and purposeful

Capture useful knowledge

Let’s start with some timeless advice from Seneca

It is the mind which is tranquil and free from care which can roam through all the stages of its life: the minds of the preoccupied, as if harnessed in a yoke, cannot turn round and look behind them. So their lives vanish into an abyss; and just as it is no use pouring any amount of liquid into a container without a bottom to catch and hold it, so it does not matter how much time we are given if there is nowhere for it to settle; it escapes through the cracks and holes of the mind.

Here he was referring to the people who waste their time. But I feel it equally applies to those who waste their experience.

Whenever you work on a project, there is always something new to learn. Maybe you just figured out the lighting in meeting room A does not allow for easy projection. How do you capture this knowledge? How do you ensure no one else does a client demo in that room? If you encounter a rare bug in one of your core libraries, what do you do about it?

Reconciliation is a useful concept in this regard. Whenever you are done with a sprint, a project or even a day. Consider what did you expect to happen vs what actually happened.

How do you foster team learning in your own organization?  Talk to me in the comment section below or on my twitter @jchex



Why you should do estimation in groups

More than any other activity, estimation of size or effort it will take to build a digital product is based on individuals. Even worse, the responsibility tends to rest on the team lead.

In the midst of the flurry of proposal writing, it may feel like a waste of time to bring in the development team to work on the estimates using a practice such as planning poker. Better use a shortcut and just call the most senior developer and have them give you the estimate.

In this entry, we will be looking at why this is a bad idea and why group estimates tend to fair better than individual estimates, no matter how senior the individual doing it.

The elephant in the room

An old Chinese parable explains this concept very well. Here is the story quoted verbatim:

    Once upon a time, there lived six blind men in a village. One day the villagers told them, "Hey, there is an elephant in the village today."
    They had no idea what an elephant is. They decided, "Even though we would not be able to see it, let us go and feel it anyway." All of them went where the elephant was. Everyone of them touched the elephant.
    "Oh, no! it is like a rope," said the second man who touched the tail.
    "Oh, no! it is like a thick branch of a tree," said the third man who touched the trunk of the elephant.
    "It is like a big hand fan" said the fourth man who touched the ear of the elephant.
    "It is like a huge wall," said the fifth man who touched the belly of the elephant.
    "It is like a solid pipe," Said the sixth man who touched the tusk of the elephant.
    They began to argue about the elephant and everyone of them insisted that he was right. It looked like they were getting agitated. A wise man was passing by and he saw this. He stopped and asked them, "What is the matter?" They said, "We cannot agree to what the elephant is like." Each one of them told what he thought the elephant was like. The wise man calmly explained to them, "All of you are right. The reason every one of you is telling it differently because each one of you touched the different part of the elephant. So, actually the elephant has all those features what you all said."

    Source: [jainworld](https://www.jainworld.com/literature/story25.htm)

The idea behind this story is that we all have different viewpoints. Until the software product is complete, it is mostly a jumbled mess. Everyone in the team sees only a small part of what the work would entail.

In short, you need the whole team to see the elephant.

Human folly

As a species, we named ourselves Homo Sapiens literally translates to wise man. We couldn’t have been any more wrong in this assessment.

Human reasoning is terribly flawed. The list of our biases is so long that not even a single volume would be able to contain it all. That is not to say they have not tried, see Predictably Irrational, Misbehaving and many other such titles.

Wikipedia has a list so long that it would fit a couple of articles and that is not considering their definitions.

In short, when an individual does the estimates. They will probably seek reasons why their estimate was right rather than getting to the right estimate.

Thankfully, we also evolved a way to combat our biases, arguments. Constructive arguments around the estimate will help everyone think more carefully about their estimate and thus raise the overall quality of the final estimate.

Deep understanding

In an article Minding matter, the astronomer Adam Frank says something very interesting

    When I was a young physics student I once asked a professor: ‘What’s an electron?’ His answer stunned me. ‘An electron,’ he said, ‘is that to which we attribute the properties of the electron’

He does go on to explain the statement. For the sake of this entry, it suffices to acknowledge that the reality of what the product will be is as much what the developers will make it, as it is what we think is an objective product out there.

If this is the case, then understanding the different viewpoints can help us get a far clearer picture of what the developers intend to build and thus a better estimate of the size and effort required.

The rule of five

I like the quote

    Always remember that you are absolutely unique. Just like everyone else.
    Margaret Mead

It reminds us that at the end of the day, our estimates will likely cluster. This is not folksy wisdom. It is a statistical fact. There is a 93.75% chance that the median of a population is between the smallest and largest values in any random sample of five from that population.

Take this rule in comfort, it means that while there is a great benefit to having a group do the estimates, the group needs not be bigger than just 5 individuals.

Do you do estimation in groups in your own organisation? Talk to me in the comment section below or on my twitter @jchex


Successfully working with a remote product owner


In today’s connected world, your client is rarely next door if even they are on the same continent as you!

In fact, with the rapid rise of the gig economy, the scrum master, development team and product owner may all be on different continents.

For the team, this is obviously a challenge. After all, you need your product owner to prioritise and guide development activities.

In this entry, we are going to be looking at some of the things that the PO can do to ensure that they are successful in their role even whilst being remote.

Out of sight, out of mind

Humans have an affinity to activities that physically engage them. Working on a project where the only contact with the other person is through screens is not natural, at least not from the perspective of our roots in the Savannah.

It is thus very easy for the PO to invest their energies in more immediate teams or even just their local friends at the pub.

To be successful, the remote PO must be mindful of this effect and constantly recommit to being engaged in the project.

Trust is the key

Rapport and trust are the drivers of all successful teams. Without it, the team would spend too much time bickering over trivialities.

As the Arbinger Institute put in Leadership and self-deception

No matter what we are doing on the outside people primarily respond to what we feel about them on the inside

It is easy to fall into the trap of thinking of your remote team as somehow less superior or skilled because well, they are far.

Even at a distance, this sentiment will be registered.

It is thus important for the PO to ensure not only that his attitude is one of camaraderie but to engage with the team as much possible even in non-core work activities. Perhaps check into slack’s #random channel every once in a while.

Let’s quickly jump into a call

I normally don’t like long business calls. They are uncomfortable to sit through, I have problems hearing what is being said and God help us if the connection is poor.

Still, compromises must be made. The bandwidth provided by even a shaky call is far more than anything that email can provide.

The PO thus must commit to remain available to the team. Sometimes this may mean working after or before their usual work hours. This sucks, the only saving grace I would say is that sacrifice deepens commitment.

I will get back to you

Ok, so calls are not always an option. In this instances, it’s useful for the PO to at least be responsive on email.

Yes, I know our inboxes are flooded, but the commitment to the project means that the PO gives priority to his development team queries.

This should also be done within a reasonable time frame. A response received three days later is a guaranteed flow killer!

Have you ever worked with a remote product owner in the past? Talk to me in the comment section below or on my twitter @jchex


Why we don’t count incomplete stories


It is the end of the sprint. This has been a fairly good one, we had set to complete several user stories among them the following:

  • As a customer, I want to be able to manage my notification frequency
  • As a merchant, I want to be able to quickly see what time my customers like receiving information from me
  • As a merchant, I want to be able to alert customers of new product offerings

To each of this stories, you had given an estimate of 13 story points. You have managed to completely deliver on the first and last item. For the second one thou, you are not quite done. While the API is ready, the feature is not all wired up yet. You feel like you are about 90% done. But the sprint is over so some work has to roll over to the next sprint. Do you assign it’s 13 points to this sprint or the next? Or maybe you assign 90% of the points to this sprint and 10% to the next?

This is a scenario that often gets played out in development shops everywhere. My simple answer would be, don’t assign any points to this sprint. In fact, don’t assign points until the story is fully complete.

Here is why.

The incomplete space is virtually infinite

It is easy to understand when I say the feature is complete or not complete. The space in between can mean almost anything. Here are some examples:

  • Can mean not coded but tests written
  • Code has been written but no tests
  • Currently being refactored

Thus my opinion of 90% done and yours may be dramatically different. I may mean that am yet to push changes to the server. You may be an advocate of measure twice, cut once and thus are now just done with the design and starting out with the code.

It’s much easier to just take a binary stance.

Feedback times increase

A key principle of Kanban is to limit work in progress

In software, this matters because work in progress increases feedback time.

Cycle time = Weeks / Feature

Let us combine that with Little’s Law

Average wait time = No of features in progress / features completed per week 
Average wait time =  No of features in progress * Cycle time

From the above, we can see that each incomplete feature increases wait time by a cycle.

With increasing WIP we get increased time to feedback. This is a vicious cycle. Eventually, you kill off all benefits that would have been accrued from the faster learning granted by agile.

Trust is lost

Agile runs on trust. The development team trusts the client to communicate the problem, give truthful deadlines and appropriate priorities. The client expects the developers to give them estimates that are correct and to deliver the best possible work that they can.

In fact listed in Values of extreme programming is the virtue of courage:

    Courage: We will tell the truth about progress and estimates. We don't document excuses for failure because we plan to succeed. We don't fear anything because no one ever works alone. We will adapt to changes when ever they happen.

Immediately the development team discovers that the feature can not be completed in this sprint, it behoves them to start a conversation with the client. Perhaps the story can be broken down and part of it moved back to the backlog? Or with this new information, the client can decide to simply de-prioritize the entire feature from the sprint.

Either way, by involving the client in the discussion, a much more holistic solution can be found.

How do you manage incomplete stories in your own agency? Talk to me in the comment section below or on my twitter @jchex


Selecting a new tool? Think about this first

Software tools are some of the most expensive products in the market. For example, to give your designers access to the Adobe suite, you are looking at $80/Month. Of course, the designed product needs to be coded, so again we are looking at $400/year for Intellij. And this are just the basics!

Yet this is not even the important metric. Each tool comes with its own learning curve, this means lost hours that could have been used productively.

In this entry, we shall be looking at the various questions that you need to ask yourself before adopting a tool.

Who is the vendor?

This is a very important question. We had previously explored it in Selecting the best vendor for your product.

Everything feels the devastating effects of entropy. This means that the shiny new tool that you just bought will one day require support from the vendor.

This can either be in the form of a scheduled regular update or a support call. Either way, you want to make sure there is someone to help you on the other side of the line.

What is the gain?

In the classical book Filters against folly, Garret makes the following statement:

    The numerate temperament is one that habitually looks for approximate dimensions, ratios, proportions, and rates of change in trying to grasp what is going on in the wold. Given effective education–a rare commodity, of course–a numerate orientation is probably within the reach of most people.

Aditya gives an example from the person we all know and love, Elon Musk. Simple Math Is The Reason Why Elon Musk Does Things That Seem Impossible To Others

Clearly, the ability to articulate the benefits numerically is important. Software vendors will typically promise you the world, unfortunately, the world is just not up for sale. You need to be able to at the very least do some back of the napkin calculations to assert if the tool will give you meaningful gains.

E.g if I currently use my personally hosted git on say AWS. I then come across a salesman for say Github, who promises that by hosting my application on their platform, I will gain 5X productivity. The fist thing to ask is how are they measuring productivity? Is it time to code? Time to checkout? Ease of finding the code? Then I would give a measure to how important this is to me. Comparing this metric and the expected gains, I can see if truly the gain is 5X and if it’s not, is it still enough to be worth adopting it?

How long has the tool been in the market?

Change is inevitable. In the world of software, this means that the tools you just bought are amenable to change. The question then is, in what direction is it likely to change?

The startup world has a term for it Pivot. This is where a startup shifts strategy in its effort to find its business model.

Obviously, the ability to pivot is of great value to the startup, to your business, however, this may not be so good. The initial strategy may have focused on speed which aligned with your own strategy, they now maybe focused on user experience and in the process trading of the speed.

How well does the tool fit within your existing systems?

Each organisation has with time built its own ecosystem of tools. More often that not, the business has figured out how to make its various components from accounting to planning tools work.

Any new tool then needs to somehow fit into this ecosystem. For example, if your entire business is made up of remote workers. Then acquiring a system that only works when all the devices are connected to the same network is going to be a disaster.

You may also want to consider how the new tool constrains future tool adoption. Tools typically provide multiple interfaces to interact with. If the new tool say exposes only JSON interface for integration, then you will have a problem adopting a SAML-based tool.

How much training is needed?

Some tools are necessarily complex and need training time. This by itself is not a bad thing. Unless of course there are no trainers or even worse, a community of practitioners for your staff to interact with.

Popular tools have a leg up in this cases, this is because there is usually a community to answer any esoteric questions that you may have. Unfortunately, the popularity also means that the tool gives you less of a leverage over your competitors.

Less popular tools may have a defining edge that takes you to the top, but then getting access to trainers maybe problematic and expensive. Not to mention, you may not be able to get help once you learn on edge cases that are just not documented in the manual.

What is your process for adopting new tools? Talk to me on the comment section below or on my twitter @jchex