Month: July 2016

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:

1. Sprints
2. Sprint planning meetings
3. 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.

Why time box?

Scrum has basic principles that power it: Visibility, Inspection and Course Correction. The 3 core principles of scrum.

Timeboxing is the meta principle.

When you time box, then certain qualities come into play:

1. 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.
2. 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.
3. 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.
4. 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:

1. Insist on wholesome adoption of Scrum. That way you can point to its rules when someone wishes to violate the timelines.
2. Assign estimated time to tasks to be done and ensure to never put in more tasks than can fit the time window
3. 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
4. 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.