When things go wrong

Have you ever noticed how colourfully the best-laid plans disintegrate when they come head to head with the real world?

The popular adage

Whatever can go wrong, will go wrong

seems to hold its own.

In the world of software development, its common to have an agreement with the stakeholders the product you are developing will be fault free and meet their needs. What then happens once the delivered product fails to meet these agreements?

Yes, even with Agile, sometimes you miss the mark and now have to hash it out with the client.

In this entry, we will be looking at how such situations can be handled in a way that makes you better for it.

Raise issues as soon as possible

As I have mentioned before

Bad news does not age well

In my experience, the most tempting reason for withholding information about the fires going on is to try to fix it before anyone else notices. Sometimes the strategy works out and you are solid. Most times, it just doesn’t. What ends up happening is you dig an even bigger hole for yourself.

Years ago when mobile phones had just hit the market, I was playing around with my parent’s phone, somehow I ended up turning it off. When I turned it back on, it requested a PIN. So I did what any reasonable child would do, started guessing! The effect was the SIM locked and the phone now asked for a PUK. Again, I continued guessing the numbers. In the end, the SIM card permanently locked and we had to part with Kshs 2000 to get a new line. If at any one point before the number blocked I fessed up, the problem would have been trivial to solve.

In your own professional practice, when a problem arises, drop the hero mentality and instead see if you can enjoin the other stakeholders to jointly solve the problem.

Take the journalist approach

It’s very easy to blame. After all, our brains love certainty even when there are no grounds for it. Thus when an issue comes up, it is easy to blame another stakeholder or even yourself.

Even if you are right, it doesn’t matter, the problem is still there!

My personal philosophy is never let any good disaster go to waste. If you have encountered a problem, this is the time to establish the what, how, when and why. By probing the incident, you will end up with insights into how you can improve your work process.

As a side effect, you learn how to separate the facts of the issue from the opinions formed around it. Humans are attached to their opinions, thus by focusing wholly on the facts, you are able to get a more productive approach going.

Prioritize the relationship

A Pyrrhic victory is a victory that inflicts such a devastating toll on the victor that it is tantamount to defeat.

In almost all engagements, the relationship is more important than the product delivered. We will allow great latitude for someone we trust.

Problems are by their very nature divisive, you must fight the urge to prove yourself right and the other parties wrong. When things do go south, this is the time to think deeply how you can use the opportunity to instil even more trust in your clients. No one is perfect, this means mistakes are inevitable, it is however quite valuable to know the other person will always be straight with you.

When complaints do come, the contract is not your shield and defender. Even if you somehow captured this case in writing and thus are not to blame, the client is not happy and that is a problem. It is better to then engage in a conversation to find out where you misunderstood each other and how best you can mitigate the situation with the remaining time and resources.

Keep moving forward

Peter Palchinsky was a Russian engineer who came up with a formula to improve almost any process.

first: seek out new ideas and try new things;
second: when trying something new, do it on a scale that is survivable;
third: seek out feedback and learn from your mistakes as you go along.

There you have it, to grow you must make mistakes, the key is to ensure the mistakes are survivable.

Thus after the mistake is done, comfort yourself, see it as a ladder to even greater things. After all, if it did not kill you, you learnt something from it.

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



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


Go deeper to become better

You have been assigned a new and foreign task, say you need to ensure that each new registered user gets a nice welcome email. Your platform of choice is laravel but you have never really worked on this task before. What is the first thing you do?

If you are like most people you simply look up the documentation and copy paste something like this to your code.

Mail::send('emails.welcome', $data, function ($message) {
    $message->from('us@example.com', 'Laravel');


You would then go right ahead and modify the code to fit your own context say

$data= ['user'=>Auth::user()];
Mail::send('emails.welcome', $data, function ($message) {
    $message->from('admin@chenchatech.com', 'Web admin');


And you are done! Now just stick this in the registration process and all is dandy. So far so good, you needed to deliver fast and you have, but is that it? Do you even understand what is going on?

Unfortunately this happens so much in programming that it’s an accepted practise and for good reason too. It’s quite easy and even profitable to depend on other peoples knowledge of fundamentals. We do this all the time and tell ourselves that later we shall take the time to go back and understand it but do we ever do it?

When crunch time comes knocking and you need to implement a novel use case in a week, you will need months just to master the basics, so why not start now?

So next time you come across a new problem how do you handle it?

First and foremost break the copy and paste habit, instead think about new concepts as a mental structure to be anchored upon existing knowledge. If said knowledge doesn’t exist, then build that!

Secondly try to understand the historical context, in our example above, try to see not just how laravel does it but how is it implemented in PHP? On what RFC is it based?

Thirdly think about the concept as it relates more generally in this case we are thinking about communicating with a just registered user. This might even give us insight into a better design maybe a class RegisteredUser where you can add this routine as well as other routines associated with newly registered users.

Lastly, think about underlying computer science concept. This is especially true for more complex problems. It just maybe that what you are trying to solve is a common problem with an efficient algorithm already discovered. Then again it maybe an unsolvable problem. Either way you have saved yourself a ton of time!

Putting this principle into practise will quickly deepen your knowledge and give you almost superhuman powers in solving your engineering problems. But all is not rosy in this world, it will become tempting to continue specializing to the point of losing the broader perspective of what is important in your project. At one point enough information will be just that, enough.

Do you possess deep knowledge in your field? Tell us in the comment section below.