Incremental Software Development Or Why Big Achievements Are Done Through Small Steps

If you’re a hardcore software developer, a journeyman set on the noble path of software design and implementation, or you’ve just started out on this great journey, chances are you’ve hit a snag in the road while getting accustomed to continuous code implementation. And if you work as part of a team, where more people than just yourself add to the codebase, then I know for sure you’ve had this problem.

In case I still sound mysterious, I’m referring to development problems arising due to asynchronous programming & software development.

First let’s identify the problem with a simple common example.

You work at a mid to large level company. You are part of a mid to large team, let’s just say somewhere around 20 developers. New requirements trickle down from the CEO and management down to team leads and then work gets assigned to you and your colleagues or you choose those assignments yourself. Whichever the case, tasks are taken and given and the job starts rolling.

For performance and tracking issues, you use a story board system, let’s say Pivotal-Tracker or Blossom. And you should. Numerous tasks are required, some are fast implementation types like small bugs and hot fixes while others represent major overhauls of previous functionalities, redesign or even new functionalities all together. Even still, some of your colleagues might not be in the same office, instead working remote from other parts of the world, in vastly different time zones. So tracking is essential.

Management assigned points based on difficulty of task and time estimation for delivery. And you get to work.

In case the problem hasn’t started being obvious, it has everything to do with team moral and overall productivity.

So how many points should be attributed to a story? 1 point, 2 points, 5 points. You might think that all depends on the difficulty of the task at hand and as such the time it will require to finish. But you’d be mistaken. So how many points should be attributed to a story?

Answer: Just 1 point. That’s it. Just 1 point on any story. Well, in all actuality, it is irrelevant, it could be 5 points at that and still make no difference. So long as all stories get assigned the same number of points. Why? We’ll touch on that a bit further down.

Secondly. How should tasks be assigned? How should assignments be attributed? Should Management be solely responsible for task assignments? Or should the developers themselves be responsible with task attribution?

There are no cut-out perfect scenarios, and like most things in life, the “perfect” solution can only be picked taking into account the particularities of each individual situation. In most cases, it implies a bit of both. So how does a perfect system look like?

Management and the sales team take time and discuss options with clients. They take a pen and paper or even better still record the meeting. In it they ask as many questions as possible about what the client wants.

The reason this is important is because, as most of you know already – or will learn soon enough via the hard and painful way – most users & clients do not know what they want. Sure, they have an idea, but for lack of a better word, they are oblivious as to what they want. Why? Because they do not know what they need and what are the requirements for that to happen – namely if they are feasible (meaning doable) requirements in the first place.

Management takes the hand written notes or a transcript of the conversation and passes it around to the entire dev team. After careful documentation, the dev team gives valuable input and feedback on what is possible to implement, what is impossible, what is easy to do (meaning cheap) and what is hard (long and expensive).

I am well aware that for you, this scenario might be out of your hand since it requires a significant level of active participation from management and from the rest of the development team.  So let’s check the next step which isn’t.

What comes next, after the goals are set and the tasks published on the story board, is to decide who gets what.

First, tasks should be put up on order of priority. What has priority can only be decided based on each individual team’s and company’s requirements.

After that, each individual dev should pick for himself a task, in order of priority, and based on his or her personal experience (strong points and weak points).

If this makes sense for you, then we will move to the next, and arguably more important step.

How should stories be published?

In my infant stages as a fledgling developer I had a story unanimously attributed to me by management. It was a complete redesign of a very important part of the companies application, the users management page. 3 points were assigned and after I branched of off develop I got to work. Nearly Two months and over 200 commits later I was almost done. All that was left were the merge conflicts to deal with. For lack of a better word, I found the whole experience akin to a nightmare.

Although I was making good progress, and spending regular hours making important progress, I was always left feeling dejected and left behind. I could not stop questioning my skill and capabilities as I was constantly seeing my colleagues pushing and merging new features in a fast paced manner leaving me questioning my performance and value to the team.

Looking back now, and knowing what I know know, I fared remarkably well given the situation. So what was the problem?

To put it simple, the ticket was huge. It was way to big. And before you point out the now obvious solution, a question arises in the minds of many developers and management personnel alike – what did you expect? It was a single task that had to be done completely from beginning to end. True enough. But I’ll still say it.

Tasks should always be split up in individual components? A task should be defined by the implementation of a single job or feature. If that sounds familiar to you, yeah, you’ve guessed it, it is the Single Responsibility Principle in application in a real world scenario.

As I’ve stated before, all these programming principles are modeled after real life practices since programming, as a profession, models real life events.

So this is how you should “attack” stories from now on. Break them up in the most small components as possible. In my example the story should have bees written up as such.

1 Base story containing the generic title and requirements – Redesign of User’s Management page.

Them a multitude of multiple stories containing each and separate functionality, or job.

• 1 story dealing with users reclassification and iteration on index. ( who are account administrators and who are general purpose users)
• 1 story dealing with each individual users edit page.
• 1 story dealing with each individual users show page.
• 1 story dealing with small UX design upgrades.
• 1 story dealing with final front-end design touches.

There could be more, but you get the point.

Now the benefits to this system are two fold.

First, in case of multiple developers tackling the same task and working together, they can separate work amongst each other.

Secondly, even if only one user does the whole task, he can now handle it in an incremental fashion. He is forced to focus on each task at a time.

He is also seemingly more productive since he pushes and opens pull requests on a daily or weekly basis instead of one giant merge at the end.

Morale is boosted and performance is increased as a result.

Management has a far better tracking of the situation. Deadlines can now be set and promises can be kept.

It is a win-win situation on all fronts. Developers get to shine and be productive and “unconfused” about their work related requirements and Management gets to score big with clients and users.

To translate this entire post in layman terms, work should be done as follows:

Client requirements should be received with as mush detail as possible.

Stories should be separated in low hanging fruits (the meat and potatoes part of the business) and “high risk – high reward” tasks (the specialization of your application)

Further down, each individual story should be further broken down to it’s bare parts, it’s most basic components and these should be made into stories of their own.

Tickets should be published on the story board in order of priority, with the most urgent ones at the top.

Team members should be trusted to individually pick tickets based first on order of priority for the company (as set together in team meetings) and secondly on personal capabilities.

New improvements, fixes and functionality get to be outputed on a continuous basis.

There are other significant benefits to using this system, to adhering to this work methodology. For example by letting devs pick small stories from themselves they can also choose stories that do not fit their strong points, so that they can learn new things and develop new areas of expertise. This helps reduce programmer specialization. You do not want to end up looking on the story board and saying – “Hmm, The online shopping cart is up for a redesign, who did development on it last time? Oh, Daryl. O.K. Give it to Daryl, he knows his way around the code” – And there are plenty of companies that resort to these tactics.

You want your whole tech team to be familiarized with the entirety of the system, the whole app, the whole code, both front-end and back-end. This helps create a kind of synergy, but more about that in a different post.