What is your inner story?

Behind every person is an inner story. A story that describes her world-view and thus her behaviour. The story may not be consciously written but silently adopted – and adapted – from local contemporary culture, childhood, genes and so on. All the books you read and stories you heard contributed to your story.

But there are sub-stories also. In physics we have had Newtonian and Einsteinian stories, and these stories constantly change. In this post I urge you to think what are your stories of software development. There are at least three different types of stories that define you as a software developer.

What is software development at very high level -story

In the last decades of software development we have not been in lack of paradigms to choose from. Many have come, many have gone. And I agree, we still are trapped in nonfunctional paradigms. Here are a few different paradigms that Alistair Cockburn pointed out:
Image51-.gif

Of course, these are a bit philosophical paradigms from methodologists and as such do not define very strictly how you will behave in every situation. But it is a foundation on top of which the other stories build. Do you have a different metaphor for software development that describes your style better? Let me know!

What is a software project –story

This is the type of story that has caused most process wars, manifestos to be written, different schools of thought to be born and continuous flux on the science side.

Educated 90´s software development

Perhaps the most common story is what was teached at school in the 90´s, being a mixture of Meyer´s engineering, Humphrey´s discipline and Jacobson´s model building. This most often resulted in the traditional waterfall-development in which each activity is carried out sequentially by specialists of each phase.

This story encourages for big, upfront design, comprehensive documentation and project management as a separate task. And testing postponed to the end of the project.

Software project is a collaborative game

In many parts, this is the original way of writing software – that is doing an reincarnation in the names of lighter-weight methodologies. You basically take a cross-functional team (preferably small) of people and trust them to get the job done. This philosophy is behind the many agile methods that coming with varying set of practices, principles and rules on the game.

Usually this story comes with iterations, incremental development, continuous integration, behavior driven design and test driven development etc.

Alistair Cockburn has even composed a manifesto for this style:

“Software development is a (series of) cooperative game(s), in which people use markers and props to inform, remind and inspire themselves and each other in getting to the next move in the game. The endpoint of the game is an operating software system; the residue of the game is a set of markers to inform and assist the players of the next game. The next game is the alteration or replacement of the system, or creation of a neighboring system.”

Cowboys on the desert

In practice, many software teams are not willing – or capable of – carrying out monstrous project framework and processes that 90´s style requires. Further, they do not have the discipline neither responsibility that collaborative game needs. Instead they work like cowboys on an unknown land: without any idea where to go, they take each confronting sack, changing direction continuously and ultimately ending somewhere leaving a disastrous mess behind.

In software terms this means that there is a bunch of individuals who are not collaborating fluently, requirements drop unexpectedly from customer and there´s virtually no communication between the customer and developing team except what is absolutely required to hand off the requirements and at the end, deploying some piece of somehow working software.

Requirements change wildly and they are implemented right away without thinking the architecture and keeping the code clean.

Systems thinking

Some go as far as saying you should not have projects at all, but think development artifacts as products. Usually projects have up-front funding, scope fixed at the beginning and success is measured in terms of meeting the scope in given time at given cost. What´s worse, the team is often disbanded and each member goes on to new projects. A new team will step in and take care of the maintenance.

Alternatively, in systems thinking the development is funded incrementally, scope is expected to evolve along the way and success is measured in terms of market share and profitability. The same development team often stays with product.

What am I as a developer –story

Finally, after each person´s beliefs about development in general and reckoning about projects (or products) each still has a different attitude towards his work

Stonecutters, living earners and cathedral builders

There´s is a great story about three stonecutters in Kitchen Table Wisdom.

It’s a story offered by psychologist Roberto Assagioli, who tells of a man who goes to interview three stonecutters engaged in building a very large cathedral. When he asks the first stonecutter what he is doing, the man bitterly replies that he is cutting stones into blocks, a foot by a foot by three quarters of a foot. With frustration, he describes a life in which he has done this over and over, and expects to continue to do so until he dies.

The second stonecutter also says that he is cutting stones into blocks, a foot by a foot by three quarters of a foot, but he adds an important piece. He lets the man know that he is earning a living for his family; through his work his children will have clothes to keep them warm and food for them to grow strong, and that he and his wife will be able to maintain their home, which they built with so much love.

But it is the third man’s response that astounds the interviewer. In an enthusiastic voice, he tells the man how joyous and grateful he is to have the privilege of building a great cathedral, so strong that it will stand as a holy beacon for a thousand years.

http://clf.uua.org/quest/2008/12/janamanchi.html

Are you just typing some freakin´ code, putting up darned CSS styles, <put here your current day-to-day activity> or are you part of  team who is building an exciting new product? Or are you just doing whatever you´re told to do so that you can feed your kids? When you are annoyed by your job what do you do? Complain about it? Ignore it? Fix the problem?

Technology lovers, tool blamers and superheroes

Besides the overall attitude to your work there are some characterizing ministories that you may have absorbed.

Are you a superhero that often works night´n´days, sacrificing your own life because “it´s the only way to save the project”. Do you think the other people on your team are inferior and you are the only competent guy?

Or do you think that you and your team are perfectly competent and suitable for the project – except that the tools are always wrong. Be it the operating system, version control software, time-tracking software, internet browser… You are doing your job perfectly but the tool just prevents you to be productive. And there is nothing you can do about it.

You may also have fallen in love with technology. Be it all the new technology in general or any given brand that has dazzled you. Anything you think is from the point of view of the newest technology.

Different types of developers

Alex Love has written a nice overview of different types of developers. Do you recognize one of the types to describe yourself?

Afterthoughts

While it may be hard to find a single story that works for you all the times, it´s important to understand your own way of thinking. Equally important is to understand the stories that your team mates carry with them. Conscious team leaders make up teams that consist of people with compatible inner stories.

Have you noticed different types of stories that define software developers? Feedback is welcome!


Tags: ,