Month: July 2016

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.

Meetings

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

How to stop it

When possible, meet in front of your scrum board. This should give context to the meeting enabling communication to be smoother and faster

Make a habit of specifying Next actions after each meeting

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

Have a clear vision.

Eliminate as many layers of abstraction as possible, if you can sketch the app, do it! We are visual creatures after all.

Talk to the users. You are not your user, make sure to talk to your target audience before the first commit is made

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.

Setup a process to identify budding software designers within the developer pool

Carefully monitor the progress of the designers. Assign mentors to guide them on their path

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

I heard a horror story from a friend of mine who was called on to fix minor bugs on an existing product. Being a high profile product they took on the client. What followed was nothing more than pain. There did not seem to be any order or rhyme to the code. As far as he could decipher there was not a single design, best practise or even guiding principle that he or his colleagues could use to make sense of the code! This by itself is not much of a shock, what is shocking thou is that this application was in production and except for the bugs, it was actually serving it’s customers!

Now just to give a little background on software design. To be able to design a non trivial application, you need basic knowledge in most of the following areas:

Information hiding

Abstraction

Encapsulation

Cohesion

Coupling

Hierarchy

Inheritance

Polymorphism

Data structures

Algorithms

A good engineering eye

This are concepts that take months to learn and years to master. They represent massive personal investment by the designer on their craft. Yet right here, is a curious example of a software application that it’s creator lacks any of this skills but still managed to somehow get it working.

Originally I figured that was a random one off, but actually it does happen fair enough to be worthy some looking into. So I did, and below is what I found to be the driving factors behind this miracles of code.

Trial and error

Perhaps the simplest, it is still one of the most powerful processes available to our species. Trial and error has proven effective in such great works as the Pyramids and the Monalisa.

In the business world, trial and error is accepted and even christened a beautiful name, Pivot.

When you start your developer journey, all you do is try and err, learn what works and keep doing that. A good number of developers just never pass this stage. Their products are mostly mediocre. But once every while a successful product arises.

Curiously when the code finally works, they will have no idea why it did. Only that it did.

Master of debuggers

Debugging is as much an art as is a science. As it turns if you are a truly great artist you can do just as well without the science!

I have met amazing developers with great command of debugging tools. They can dig through the stack trace and find out what went wrong with an exceptionally high success rate.

By leaning on this clutch, this bunch have discovered the secret to never ever having to improve their design skills.

Team jobless

Yes there are some of us with a whole lot of time and nothing to do. Of course except write that one application.

Eventually even rocks get worn down by constant flow of water!

With nothing better to do, this particular group of developers will put in massive time to paying Technical debt. They will explicitly handle all cases, copy-paste-edit existing code, rewrite modules just whatever it takes to get the code to work.

There you have it. Yes it is possible to build a good product without good design, but you better be a really lucky person.

Have you ever encountered applications that work because they work? Talk to me on the comment section or on my twitter @ jchex

Recently my brother took it upon himself to teach me Scrabble. On our first try I played the word timeboxing. By the numbers on the top of the tiles I could tell I was to be a winner. He challenged the word, and pulled out a dictionary. And that is how I got zero points on that turn.

Clearly my brother and the authors of the dictionary he used are agile noobs! Will you not join me in educating them?

What is a time box?

In the simplest terms. A time box is a fixed period of time allocated for carrying out a planned activity.

We all have used time boxes in our life. When you schedule to do your morning 30 minute run, that is a time box. When you have a 2 hour meeting, that is also a timebox. A three month semester, still a time box!

The concept of timeboxing is all around us.

In agile software development, timeboxing appears all over:

Sprints

Sprint planning meetings

Daily scrum meetings

In fact as a schedule oriented practise, scrum explicitly seeks to cut the scope to fit the schedule rather than adjust the schedule to a bloating spec document.

You meet deadlines. No more extending the date, if it doesn’t fit it’s chopped off. This then means there is time for Inspection and Course Correction.

Incremental progress. By timeboxing, you can only do limited amount of work at any one time box. As such the project gains Visibility and has natural breakpoints to allow for Inspection by all stakeholders.

Prioritization: Faced with short time windows, the client and the developers have to prioritize what is to be done, effectively reducing any waste on the project.

Engaged developers: In my experience, I have come to find that more than money, challenging project or even a good client, clear sign of progress to a big goal is the biggest motivator. While not a core scrum principle, you really can’t do much with burnout devs.

How to time box

We already know how to time box, just schedule a time to do stuff. The challenge is actually sticking to the time box.

Here are some of the tricks I have found to work:

Insist on wholesome adoption of Scrum. That way you can point to its rules when someone wishes to violate the timelines.

Assign estimated time to tasks to be done and ensure to never put in more tasks than can fit the time window

Don’t delete suggestions, put them in a backlog. No one likes to have their ideas thrown in the garbage can (even if it deserves it). So instead put ideas that can’t be executed on this time box in the backlog to be reviewed in the next planning meeting

Adapt. It will take some time to figure out the time box size that best fits your team. Don’t fight the learning process, instead play with the time. Whilst I advocate for 3 week sprints, there is nothing wrong with a 1 week sprint or even a 5 week sprint. One of the most senior developers I know leads her team using 5 week sprints and they are a super effective team.

I trust that you will be implementing time boxing in other areas of your life! Say to keep it all in balance?

Do you use timeboxing regularly? Get to me on my twitter @ jchex or on the comment section below.