On becoming a software engineer


About a week before this writing, I got an email from my friend. She asked, “How do I get to be good in Python before my interview next week?”

This is not an isolated question, with all the hype the field has been getting over the past years, it has created an illusion within the general populace that it’s easy to become a master engineer.

By consuming media through computers over many years, many have been disillusioned into seeing their familiarity with software products as wisdom into how they work.

Still, just like any other discipline, software engineering can be mastered using time tested techniques.

In this entry, we shall look at what I believe is a viable path towards becoming a master.

Make the big decision to make the smaller decisions

The common misconception is big decisions matter more than small ones. Thus the new year’s resolutions list or the strategic decision making seminar.

In practice, it is the small decisions which are the hardest and the ones that matter the most.

Deciding you want to learn how to code is easy, deciding this Friday evening you will not go out with your friends or watch Netflix but will instead wrangle with design patterns is the hard one.

Find a way to get feedback

The easiest person to lie to is yourself. Have you ever met an individual who first saw an IDE two months ago and today they call themselves senior developers? Well, I have. They are not even lying, they absolutely believe this to be the truth.

The problem this individual faces is they have no idea how they compare to everyone else or what the industry demands of an engineer.

If you can make it through the first arduous days and weeks of programming, it’s very possible for you to be able to hack a semblance of an application. This does not mean you have a programming product.

Brooks explains:

This is a program that can be run,tested, repaired, and extended by anybody. It is usable in many operating environments, for many sets of data. To become a generally usable programming product, a program must be written in a generalized fashion. In particular the range and form of inputs must be generalized as much as the basic algorithm will reasonably allow. Then the program must be thoroughly tested, so that it can be depended upon.

To grow then you must push yourself to work with others, to put your code out there in the world to be scrutinised by others, I assure you, it will make you better.

Build it into your identity

There is no done. The field is so wide, even if you dedicated every single waking hour to consuming the literature available, you would die before you had it all.

Is this discouraging news? I would like to think not, it means your life will never lack purpose. It means every day there is a chance to experience the subtle joy that arises when you learn something new.

Thus you must commit yourself to becoming an engineer, to continuously grow and learn. Becoming better needs to become a natural part of your life just like say eating or breathing. Have you ever met someone who is now a master of breath and now no longer needs to breathe?

Where are you on your path to mastery? Talk to me in the comment section below or on my twitter @jchex


What are the different types of requirements and why does it matter?


A software product is usually built with a purpose in mind. There is a reason a good number of web application domains end with “.io “. It literally means Input Output.

Your product takes in some raw information and returns more valuable processed information.

As usual, the devil is the details. What does raw information mean? What does output mean?

Scrum typically adopts user stories as its template for expressing its requirements.

This simple structure of:

    As a __
    I want to___
    So that __

Elegantly captures what the software should do and why.

Still, as the product gets bigger and the requirements pile on, I find it useful to impose some categories on the backlog.

In this entry, we will be looking at some categories which I have found to be useful.

User requirements

At iHub, we pride ourselves in our Human Centered Approach. The simple reason is it works.

The software serves people. At the end of the databases, activity streams, object storage etc is a person trying to get something done. Your success is measured by how successful this person is.

It then helps to acknowledge user requirements as a category on its own.

A typical requirement would be

    As a *researcher* I want to *have my results sorted by relevance* so that *I can get my work done faster*

Business requirements

We talk about the wonders of technology, from the aeroplane to the mini computer in our pockets. Yet, I would argue the biggest invention by humans was the enterprise.

Businesses, are the engines of our society, working behind the scenes, they provide us with all our material needs.

No matter how good, the software or how well it serves the users, if the business does not provide value to its owner then it’s as good as dead.

With this in mind, you must seek to also clarify why it is the client wants the software product built in the first place.

This is usually captured in the client’s vision statement. Of this, the software serves only a part of it.

An example of vision statement from Amnesty International

A world in which every person enjoys all of the human rights enshrined in the Universal Declaration of Human Rights and other international human rights instruments. 

If you happen to be contracted by Amnesty International, you need to remember to imbue this inspiring vision in every line of code you ship.

Non-functional requirements

Robert Gardy in his 1992 book Practical Software Metrics for Project Management and Process Improvement

Came up with the acronym FURPS+

This represents:

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability

The “+” in FURPS+ also helps us to remember concerns such as:

  • Design requirements
  • Implementation requirements
  • Interface requirements
  • Physical requirements

The idea is in addition to doing what it does, software is also required to do it well.

How effective do you think Google would be if it took 5 minutes to give you a response to your query?

I believe by categorising your backlogs in this way, you will able to get more ideas on what is to be included in the final product as well as appropriately prioritise the various backlogs resulting from it.

How do you categorise backlogs in your own organisation? How did you handle it? Talk to me in the comment section below or on my twitter @jchex


Where do unrealistic schedules come from?


This situation is so common, it is by now something of an industry standard. There is almost no project that I have stepped into that had an appropriate amount of time scheduled for it.

You have to wonder why after all these years we still suck at allocating enough resources to get the project done in time.

In this entry, we will be looking at some of the common factors that lead to unrealistic schedules.

External deadlines

Development happens in a context. Unless it is a hobby project, you can be sure that whatever you are working on, someone else is depending on your work output for them to do their job.

A special case would be where the bid specifies the timeline in which the product must be built. In this case, submitting a longer timeline, even if justifiable may mean losing the project.

Since the project is still of interest to the team, the team takes it on knowing full well how tight the deadline is in the process displaying a mix of childish optimism and wishful thinking.

Best case estimates

Murphy warned us:

    Whatever can go wrong, will go wrong

Scrum and other agile techniques give us robust estimation tools. But even with those, we more often than not end up with a range, say 3 – 5 months.

Unless you don’t like promotions, who wants to go to the boss with the higher estimate?

Of course, the problem with the lower estimate is that it holds the implicit assumption that everything will go right.

This is a dangerous assumption, you take it for granted that you have the best tools, language, physical environment, skills etc. When something does eventually go wrong, you find yourself with an unrealistic schedule.

Feeling up to a challenge

For reasons that are beyond me. Some developers prefer working under insane conditions. Something about an all-nighter makes them feel like heroes.

Whether inspired by cut throat work environment or personal bias, teams in these kinds of environments will consistently underestimate how long the project will take.

Even if the pressure is acceptable in the short run, the effect on the team morale and product quality are bound to suffer. Better to have a reasonable schedule and spend any extra time beefing up the quality.

Belief that developers work better under pressure

Authors of the Design Sprint state:

    Times of need can be artificially manufactured by creating deadlines. Our brain doesn’t know the difference. When you create deadlines, your brain stops procrastinating and gives you what you need.

It is easy to extrapolate this kind of thinking to the entire project.

While you do need to pace yourself, you need to be very careful of the kinds of commitments that you make. In a previous entry Estimates, Targets and Commitments. We looked at the dangers of confusing the terms.

You don’t want to make a commitment to your client based on the belief that somehow the deadline will boost productivity if you must make such a commitment, let it be internal.

Scope creep

Inevitably, new ideas will come in. Change is a core part of the software development process.

The problem arises when new changes are introduced to the project but nothing is removed from the backlog. As new features are added, eventually the entirety of the work pushed the project to an unrealistic one.

We have looked at this problem in greater detail here Managing scope creep. The TL;DR is any new change is also a chance to renegotiate commitments.

Have you faced unrealistic schedules in your own practice? How did you handle it? Talk to me in the comment section below or on my twitter @jchex


Dangers of overspecification

 photo folding-rule-705668_1280_zps1zwo3f8q.jpg

Software projects tend to be expensive endeavours. With average salary for a single senior engineer topping USD 100,000/year an engineering project just maybe the most expensive engagement that the client has had to make.

It is no wonder then that the client would like to derisk the project as much as possible. The most obvious route to this outcome is to specify in great detail what it is that you want.

As a client you can then go wild specifying exactly how the screens will look like. Design flow diagrams, state diagrams, UML diagrams and just about any other diagram you can Google.

What you may not understand is that by over specifying the technical details you put your project in more jeopardy. To understand why, let us look at a classical engineering problem.

In the earlier days of the elevator business, Lift companies faced a barrage of complaints from their users on the lifts being too slow. The most obvious way of solving this problem would be to splurge on research to find out how to make the lifts faster and then spend further in development to bring the insights to life.

Thankfully an engineer identified the real problem. The issue had nothing to do with the speed of the lift but rather the perception of slowness. In short people were bored. The ingenious solution, install mirrors. This was a perfect solution, cheap to install, could be retrofitted into existing designs and the riders loved the chance to explore their vanity!

At iHub we run projects through a design sprint. The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.

The design sprint helps answer the question, are we building the right product?

This sprint has proven to be the one with the highest ROI. Not because any software is built to handle the problem but because the team consisting of the developers and the client work on problem identification.

When a client walks in and hands the technical team a detailed specification document, the implicit assumption is that they know the problem and they have the solution for it. This assumption is woefully wrong.

What if it’s not, what if the Business Analysts from the client’s side actually have it nailed. Is all that remains simply for the developers to knock it off?

Unfortunately no. Change is the only constant. As the product gets developed and the idea moves from the more abstract realms, new requirements are guaranteed to arise. This changes will then become a monster of a political problem. A lot of work by a lot of people goes into writing out a detailed spec document. Changes to the document imply that somehow the authors were wrong.

People will more strongly cling to their ideas in the face of contrary evidence. The phenomenon is so well known, psychologists have a name for it Confirmation bias This human factor is almost certainly going to run your project to the ground.

Yet even if the project was somehow able to escape all the previous pitfalls, over specification tends to make the project more expensive than it needs to be. Specifying too much detail at the beginnning of the project means that you can not use commercially available software. While the third party option may not look exactly the way you envisioned it, it just might be able to deliver all that was required of it without much hustle. The economics of buying over building have been proven, let them work for you.

Finally, even well meaning clients may just lack technical insight into their own problem. A spec document in this case is then thinly veiled software design. Software architecture is a field in its own right, practitioners of it have earned their stripes from tens or even hundreds of projects before this one. Do you really want to dismiss all this experience?

How do you handle over specification within your own projects? Talk to me in the comment section below or on my twitter @jchex


How to proactively motivate your developers

 photo adventure-1807524_1280_zpsp9fxvtwy.jpg

If your business relies on developers for its success, you are worried about losing some of your best within the next year. If you are not, you should be, the turnover rate is surprisingly high.

In an industry where anyone of your employees can become a competitor with virtually zero cash investment, to begin with, you best find a way to build loyalty.

In a previous entry, we talked about some of the things that you may be doing to demotivate your developers and how to fix it. In this entry, we will be seeing how to be more proactive in motivating your tech workforce.

Build shared purpose

In 1995, Stephen Hawkings came up with a rather colorful description of the human race.

    The human race is just a chemical scum on a moderate-sized planet, orbiting around a very average star in the outer suburb of one among a hundred billion galaxies. We are so insignificant that I can't believe the whole universe exists for our benefit. That would be like saying that you would disappear if I closed my eyes.

The universe is large and for the most part doesn’t care about us. John Truant explains the concept further on his own blog. Crucially, he highlights the fact that we have to create meaning for our own lives.

Your greatest developers are acutely aware of how short life is. They want to do something meaningful with their life. Luckily, at this moment, they are working for your business, their passion and zest is thus available to you. Your task is to continually reflect the meaning of their work to them.

Are you providing medical care to the poorest of the poor? Take some of your techies to the ground. Are you streamlining government operations? Let your techies see the appreciation of your countrymen as they get service in minutes that would have taken weeks.

Let them make and own their decisions

Command and control as a strategy is just not feasible for a tech company.

Tim Hartford in his book Adapt: Why success starts with failure puts it beautifully.

    All you need are people with good judgement in other parts of their lives who care about you and will give you their honest opinion with no strings attached

Becoming a master software engineer is hard, even getting to a decent level requires a great amount of skill and effort. If on your staff you have someone who has achieved this status, they should get bonus points for resilience, patience and self-drive. In short, all the qualities you want in a good decision maker.

By providing only the higher objectives of the product or the business and letting the team hash it out. You will be pleasantly shocked at the novel ways that will come up with.

Provide time, space and resources to grow

I find it ironic that some companies will invest in expensive gaming equipment for the office but find conference costs to be wasteful. Even worse are organizations that give a ton of lip service to growth but provide no means of making this possible.

A while ago, I tried writing out an application using one of my favorite frameworks, Laravel. Shamefully, I no longer write as much code as I used to. The last time I wrote a production level app, Laravel was in version 5.2. At the time I was trying to write out my application, Laravel was at version 5.3. This should be easy peasy, right? Wrong! The entire framework had pretty much changed. Even the underlying language, PHP, has changed from PHP5 to PHP7! The migration doc qualifies as a mini-book!

The point is that technology tools and processes change really quickly. Thankfully the change is mostly for good. You want to harness this change to serve your customers better.

You must then provide your developers with the time they need to learn new technologies. As they are learning them, you must allow them the space to experiment.

In his book Curious: The Desire to Know and Why Your Future Depends On It Ian Leslie makes the point.

    A system will learn more of it explores more possibilities. But it will be more effective if it acts on the most likely one.

You want your developers exploring as many possibilities as possible.

Exploration is no cheap endeavour. It cost USD 13.25 billion to find the Higgs Boson, arguably the greatest discovery of our time. You can afford to factor in professional development in your budget.

How do you motivate developers in your own team? Talk to me on my twitter @jchex or in the comment section below.


Negotiating tight schedules

I follow very few TV programs. One that I happen to love is called game of thrones.

In one of the episodes, one of the characters demonstrates power in a brute way. Jeremy Sadler gives a great summary of the scene EXAMINATION OF A SCENE: CERSEI AND LITTLEFINGER

As developers, we sometimes come into direct contact of this kind with corporate politics. Not being used to dealing with politics, we usually end up feeling hopelessly trapped like little finger.

In my last entry, Dangers of underscoping I highlighted the importance of pushing back on unrealistic schedules. Thankfully most clients don’t walk around with armed guards. Even better, the client wants their project to be successful. Being the technical one, you should be able to provide some solutions to the schedule dilemma.

For this entry, we are going to look at some of the more effective ways to ease schedule pressure without offending the powers that be.

You ain’t gonna need it

Pareto law, otherwise known as the 80/20 rule states that 80% of the effects are caused by 20% of the factors. This is just as true in software Chaos report 2015.

A good number of the features that the client is requesting, they will probably never need it. Telling them so is however not likely to be an effective strategy. What would be an effective strategy is suggesting that an MVP be built first.

The MVP would then inform the next work to be done. This is good for the development team because now they have less work to do with the available schedule. It is also good for the client team because they get their product to their customers faster and at a cheaper rate.

Highlight time consuming features

Believe it or not, it may not be as obvious to the client that features that they are requesting take inordinate amount of time. You may find for example that initiating an automated refund policy consumes four weeks of development time, but only a minute to explain the functionality.

Based on your estimations, you can tell the client how much it actually costs in terms of development time to roll out the various features. They may then chose to drop time consuming features that have little value to the project.

Buy don’t build

For all the vendor software available in the market, you maybe surprised at how much needless development actually goes on.

Sometimes a bespoke solution that would take weeks or even months to develop could be easily replaced with a generic one that takes minutes to install. Sure it may not be up to the quality that you expect but if its not core to the clients business then sometimes just enough is all you need.

For projects that are really squeezed for time, I would go so far as to recommend that you build the project in a way that aligns with existing third party tools.

Bigger team

If you are not yet deep into the project, more developers can make the project go faster. This can be an option for clients who don’t care about the budget as much as they care about timeliness.

This option is a dangerous one for new products. This is because the scope may not be clear and bigger team means higher communication overhead.

Motivate the team

Energy acts as an accelerator of productivity. If all else has failed and now you must work with a tight deadline, then it’s time to sufficiently psyche up your developers.

A trip to the coast, promise of new devices or even just their own private space. This external rewards can prove to be the elixir that burns all the stories in half the time.

Be warned, this strategy will not suffice over the long term. Eventually burn out catches up even to the most energetic of us.

How do you negotiate tight deadlines? Talk to me on my twitter @jchex or in the comment section below.


What to measure

My colleague, Kirui, wrote a very intriguing piece on using data to manage his team. I started using a data-driven model to manage my team — here are the results

As you already guessed, I am a big believer of data myself. At the end of the article, he makes a call to you to also join the bandwagon, but with the caveat that your model will likely be different.

In this entry, I will talk a bit more about the adoption of such a model and how it would look like for you.

To start with, the obligatory quote.

    What gets measured gets done

This is the mantra that I live by. You see, in most software teams, metrics usually take the back burner with the flawed assumption that what they are doing can’t be measured or computing metrics takes time from critical coding activities

The first assumption can be easily refuted by observing that anything that matters must have observable consequences to a degree.

On the second, the truth you rarely need more than two or three metrics. In fact, I propose that a metric is only useful to the extent that it informs a decision.

Then to get your metric, you must answer the following three questions:

  1. What concept are you trying to measure?
  2. What defines the Goal?
  3. What can show you if you are making progress towards the goal? (The metric)

This method is called the GQM model, advanced by Victor Balasi GQM

Let us start with Kirui’s model:

What concept are you trying to measure

How can I keep my business sustainable while having full visibility into its operations

What defines the goal

Are we profitable? Can I know in advance if this is about to change?

What can show you if you are making progress towards the goal

Billable hours/non-billable hours Future opportunities expected value

For a software team, the questions are likely to be answered a bit differently

What concept are you trying to measure

Are we still on time and budget?

What defines the goal

How much work is still remaining? How much money is still remaining? How much value has been delivered?

What can show you if you are making progress towards the goal

Features developed / week Customer ratings

As you can see the metrics to be used are quite specific to your goal, so then what are the common characteristics that would make a good metric?

Simple and Easy to compute

Software development should be fun, whatever metric you chose to use should be simple to use and compute.

An example of a good metric would be:

Velocity = Story points delivered/no of sprints

An example of a poor metric would be:

Velocity = Lines of code/ no of hours

This metric is hard to compute as it requires investing in some kind of time tracker and a line counting program.


Data is just a tool. For it to be of any value, it must be of use to the person utilizing it. In this sense then, you must consider who will be using the metric to make a decision.

Eg: Utilization rate, is a good metric. Anyone can clearly understand that a 10% utilization rate is bad. Return on resources is not a good metric. Although it conveys similar information, it is not intuitively clear, in fact, it comes off as a bit judgemental.


Metrics measure a concept. The only acceptable reason for a metric to change is if the underlying concept has changed.

As such you want to avoid subjective measures as much as possible.

Show progress clearly

If you have made steps towards your goal or otherwise, the metric should reflect this. Even better, the metric should lend itself to extrapolation so that you can “see the future”.

Metrics such as Profit/Quarter or Features/Sprint are always positive if the number is higher. A metric such as LOC/Hour may be good if higher or may indicate the developer is bloating the product.

What metrics do you use in your own organization? Talk to me on my twitter @jchex or in the comment section below.


Identifying and plugging money leaks

Did you know that you maybe losing up to Ksh 3.9M (USD 39,0000) every year?

Software development studios are notoriously hard to grow to profitability. Good reasons relating to the complexity of software itself exist but there are other ways in which software development firms are just plain wasteful.

In this entry we will be looking at some of the leaks that dry up your bank and how you can plug them up.


Of course this had to be first on the list! Developer rates are still sky high. You would be lucky to find a good developer at a rate of USD50/hour. Now suppose you have 3 developers on the team. If you have an hour long meeting everyday then the cost of the meetings is

39,000 = 50 (rate) * 3 (no developers)  * 5 (days in the week) * 52 (weeks in the year)

Your situation may not exactly match up to the hypothetical one I just described but I am sure you can derive a parallel in your own organization.

How to stop it

  1. Never call a meeting without specifying the agenda
  2. Before pulling in a dev, ask yourself if it is really necessary that they be in that meeting
  3. Respect the timebox when time is over, its over
  4. When possible, meet in front of your scrum board. This should give context to the meeting enabling communication to be smoother and faster
  5. Make a habit of specifying Next actions after each meeting
  6. Keep it short! In fact if it’s a daily stand up, 15 minutes is the maximum allowed

Vague requirements

The process of requirement gathering is challenging even to experienced hands. It is however an important problem, if your developers don’t understand your vision then nothing on this earth can save your project from flopping!

A good process such as Scrum helps a lot in detecting and correcting issues but sometimes you need to dig to the heart of the issue.

How to stop it

  1. Have a clear vision.
  2. Eliminate as many layers of abstraction as possible, if you can sketch the app, do it! We are visual creatures after all.
  3. Talk to the users. You are not your user, make sure to talk to your target audience before the first commit is made
  4. Observe users. Sometimes the users just don’t know what they want, in such cases observe them. The time you will save will be worth the cost

Product defects

For those of us unfortunate enough to have had to maintain poorly written code, you quickly realize that solving the issues is akin to playing a sadistic version of Whack the mole. For every bug fixed two more appear randomly and the process continues on ad nauseam.

How to stop it

If the code is in production then carefully refactor it to make sense and then start the fixes. However if you are lucky enough and you are in the first weeks of development, it is more advantageous to come back to the design board and start afresh.

For a longer term strategy, you need to grow developers on your team.

  1. Setup a process to identify budding software designers within the developer pool
  2. Carefully monitor the progress of the designers. Assign mentors to guide them on their path
  3. Pay for a conference, or two, actually pay for at least one conference each year

Those are in my experience the top three ways that consultancies waste their developers time. What are your top 3? Talk to me on my twitter @ jchex


Why Developers Should Prototype

Prototype, this is a term usually thrown around by designers and other professionals in the UI/UX space. It is such a shame that the practise is not nearly as popular in developer circles especially considering the great savings in time and cost it affords its practitioners.

A prototype is defined by Wikipedia as an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.

As I have said before waste is evil that includes waste of your own time. In this entry we will be discussing how prototyping is an essential tool in every developers toolbox.

A picture is worth a thousand words

Even for the most eloquent humans, expressing their ideas in words is usually a challenge. Now let us not kid ourselves, as a group we are not particularly eloquent. Prototypes provide a far clearer channel of communication.

By sharing your idea using even a low fidelity disposable image you will communicate a wealth of information.

Manage scope creep

No matter the tool we use there will always be a bit of ambiguity between what you and the client think needs to be built. Why not clear out the air by instead agreeing on a prototype?

I know of a friend of mine who keeps the initial sketches till the end of the project just in case the client gets creative on features but does not want to finance the creativity.

Run experiments

After spending months building a product that no one wanted, Eric Ries quickly discovered that the market does not care about effort. He then started the Lean Startup movement. I highly recommend you pick up a copy of his book The Lean Startup.

A key idea in the book is that you should not commit too much before you have validated your ideas. Prototypes are perfect for this type of work. They are easy to build, show and then discard.

Incremental development

If you estimate it will take you more than a few months to complete any feature, think if you could get some value by instead first building a prototype of the feature. If the feature works and is accepted then go right ahead and flesh it out to full on feature.

This may not be a very popular way of developing software but at least you will not be forced to discard hundreds of hours in effort if the end user rejects it. If the feature is a success then you already have production code ready and you just need to add a few more bells and whistles.

Tap into the most powerful process

In 1975 John Gall came across this pithy observation

    A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system

Evolution is a very powerful process and you want it on your side.

One way of doing this is by building prototypes and evolving them based on feedback from the stakeholders till a system that is useful emerges.

How do you use prototypes in your own practise? Tell us in the comment section below or tweet at me @jchex.


10 common ways software projects fail

A paradoxical scenario plays out all too regularly in a good number of software development studios. The organization hires great developers who have done great things in the past and put them on a project only for them to woefully fail.

Before you go on and judge the team as incompetent perhaps its time to look inward and see maybe the teams fail because of your own managers and the systems under which the developers work in.

In this entry we will be looking at some of the most common ways that software projects fail owing to process failures.

Analysis paralysis

Knowing exactly what is to be built plays right into our need for control. Control over the budget, over the schedule and the time. For all but the most trivial projects, this endeavour is doomed to fail. The reasons for this inevitability are varied, I have previously talked about it in One design to rule them all.

Thankfully the industry has elegantly solved this problem. The answer lies in agile software development. In agile and its practises (XP, Scrum) you don’t need to know everything. You leave room for flexibility as your team knows more and more about the project. See Scrum in 4 easy steps.

Negative peer influence

Throughout our formative years we were warned of this beast called peer pressure. Usually was related to drug abuse, teenage pregnancy, crime and all other decadence of youth.

Yet in our professional lives peer pressure is still as real and even more powerful.

The truth is, the opinion of the group will more likely be shaped by the loudest mouth around. This can negatively affect productivity of your most valuable team members especially if they are the silent type. In case you are wondering a good number of developers are the silent type.

To overcome this kind of peer influence. You need to ensure that your decision making process actively defends against it. An example would be by using anonymous feedback mechanisms and acting quickly to discipline errant members.


It is natural for team members to feel closer to each other as compared to the other members in the organization. This tendency however can rapidly degenerate into lack of respect or even worse outright hostility between teams.

To beat silos you need to encourage cross team collaboration in a way that highlights the strengths of the team. Self organizing teams working in flat hierarchies are the ones most likely to deliver this kind of collaboration.

Vendor lock in

It’s very easy to get tied into a particular vendor products especially when the products initially boost your production speed. When this happens you lose agility and are forced to build your products around what the vendor allows you.

Some level of commitment will obviously be needed to make any progress but ensure to have done proper due deligence and design your own solution in such a way that the dependency is clear. See Hexagonal architecture.

Over engineering

By and large developers are smart people. Left to their own means they will come up with the most complex design possible for the particular problem you are trying to solve.

Unfortunately the cost of implementing the design may just not be worth it especially for smaller projects or on the onset when the product is not yet clearly defined.

A close cousin to over engineering is gold plating. In this case, the developers put in extra features in the hope of impressing the boss or the client.The strategy largely fails as the client will either be confused by the cruft or refuse to pay for the time used to develop it.

Comprehensive documentation

Documentation is critical to a successful product. Over documentation however steals valuable developer time. It is also worthwhile to note that end users expect the product to be simple enough to use without referring to any documentation.

Invest in good UX to mitigate the need for more documentation, let the product and the code self document. See Name well or go home.


On project onset you likely have months to get the work done. In this cases procrastination sets in

Then towards the end of the project the developers are suddenly on fire working 100 hour weeks to get the project done. This is an unhealthy practise that leads to a phenomenon called the Death March.

The death march is an unfortunate situation where everyone in the team knows the project is headed for failure but continue on anyways.

To deal with this, work needs to be done in defined time box. Scrum allows for this by the practise of arranging work in sprints.

Super developer

Believe it or not super developers are not good team members. The reason is the rest of the team starts blindly trusting on the developer’s super human technical ability to get things done.

Very quickly, this developer will turn into a bottleneck for the entire team grinding work to a halt.

In addition the reverence paid to the super developer may mean you miss out on the creativity of the rest of the team as they wait for all the answers to come from the one person.

If in this situation the best course would be to ensure the super developer shares their knowledge with the rest of the team.

Poor communication strategy

The best way for humans to communicate is face to face period. Using email as the primary means of communication means a lot of the nuances get lost in translation.

In case you run a distributed team, try create an environment that imitates a co working space as much as possible. Tools like slack and hangouts are perfect for this task.

Bad manager

Bad managers come in many forms. The most common being the micro manager and the hands off manager. Both types of managers are bad for the team.

This types of managers drain the energy from the team and suppress their creativity.

Again agile techniques with the concept of self organizing teams and natural authority come into play. Here you let the team be responsible for its own success and let positive peer pressure work for you.

Have any of the factors mentioned above affected your projects? Tell us in the comment section below.