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

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail