Conscious Development

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.
(more…)

Listening to Ivar Jacobson’s talk about closing the gap between business and IT gave me an idea, what software development methodologies are all about.

During the 50 years of software development we have seen a plethora of software development methods. Every ten years comes a new methodology, a new solution, to the same old problems we have been fighting for the whole 50 years. And will be fighting, dare I say, the next 50 years. One weapon used in the war is development methodologies. But what really is the essence of a methodology?

(more…)

Inspired by my colleaque’s post about best books on web development, I decided to share my list of books about software development on general. I found a good web site for sharing books and reviews, GoodReads. I’ve shared the most interesting books from past few years. Books vary from programming to designing, from project management to team leading, from methodologies to practises. As I believe, that over-specialization kills productivity, I like to have a broad understanding to the craft.

Here’s my list: http://www.goodreads.com/review/list/2854969?sort=rating.

Here are some highlights from the first day in Scan-Agile conference.

(more…)

AKVA club of HETKY organized a seminar about agile, scrum and testing. It was a two-day cruise from Helsinki to Stockholm and back and there were many speakers from different backgrounds. There was a common (though unplanned) theme – doing agile is not easy. (more…)

A while ago I attended an evening organized by Tietotoviikko. They had a few presentations and an ending panel discussion having members from both client and supplier side and also a researcher.
The topics of discussion were IT-suppliers ability to keep their promises, customers’ expectations towards their suppliers and what makes real partnership.
(more…)

Today’s software development is more challenging than ever. Yes, in some part it’s a lot easier with higher generation tools compared to assembly languages, but I claim that requirements have raised even faster than the abstraction level in tooling. (more…)

This post also got deleted in hacker attack. It was mainly about my talk in a Nice tuesday event.

Documentation is often considered a distinct phase of software development. Very few admits enjoying documentation. It’s become the dark side of development which is most often tried to be left undone. The excuses are many, misunderstood agile software development processes being one the most recent. “We use Extreme Programming – we don’t make any documents!”

If documentation is kept as a separate phase, performed after coding, we will face similar problems as we do if testing is postponed until coding is finished:

1. When we run out of time, the phase in question won’t get done
2. The phase will be an enormous effort and unpleasant as such, we are coders after all. Documents are easier to write in smaller parts. For example, writing down what you have accomplished this day isn’t such a big deal. It’s easier to write when you still remember what you were thinking.
3. The task is easily given to someone else. It’s most efficient when the same person wo wrote the code, also writes the documentation.
4. The outcome of the phase are of no use to the previous phase: if documents are written/tests done along with coding, it will be profitable immediately. You’ll think about your code from a different point of view and you may even find a major flaw in your design!

I hear often “I’ll document the code when it’s finished”. But as often the code will get taken to production before it’s ready. And at that point there’s no documentation.

So, always document your code as you make progress!

Christmas is wonderful time for reading. You don’t have anything more meaningful to do anyway

Mike Cohn’s Agile Estimating and Planning happened to be on top of my reading stack. What a wonderful book it is! It stroke right into my thinking about conscious development. He provided excellent advice on estimating projects, prioritizing features, planning projects, planning iterations, calculating benefits, communicating progress, scheduling etc.

Most often these things are either done hastily or not at all. But you really have to do them, and do them consciously.

Most projects contain a tremendous amount of uncertainty. This uncertainty is often not fully reflected in the schedules and deadlines that project teams create. There are times when this uncertainty is so large or significant that extra steps should be taken when estimating the duration of a project.

The bottomline is this:

• You have to be able to justify any user story / project
• Do the planning, make the plans visible, and change them as needed
• Admit the uncertainty there is and plan for it
• Make wise estimates don’t just have a guess

Highly recommended to everyone! Really, I can’t say is this book for developers or managers. It gives excellent advice for project managers and project owners on prioritizing features, on the other hand, it says a lot about estimating the size of a user story – an activity best done by a developer.

It matches my thinking: there should be no project managers, developers and customer – there should be unified teams. And this book is excellent reading for a team!