Developer Haiku's



For the team prize competition this time, someone came up with the idea of doing Haiku's (short Japanese poems), for why our team should win.

I was thinking what about Haiku's for developer's or software development in general. We have the SOLID principles, We have DRY and KISS. We even have Kata's and Koans. But there doesn't seem to be that many Haiku's.

What is a Haiku?

According to Wikipedia, in essence a Haiku is a cutting poem. Often made of 3 short sentances, having 5 - 7 - 5 syllables respectively. They're often associated with an image to add context to the poem. For help counting syllable's I found haikuwithteeth which seems to do an ok job of counting syllables. There's also Haiku Village which has a nice little community. You could even write a Haiku generator if just writing a Haiku's to easy.

Some examples

Here's a few attempts at making a Haiku for software development.

First fail with red rage

then rafactor with calm tranquility

then be the code green

Less is More Haiku

Mostly, more or less,

Less is almost always more,

Simple if you can.

Big up front design

optimize prematurely

agile you are not

Any better ideas?

Well that's my first stab, any more people can come up with?

References

http://en.wikipedia.org/wiki/Haiku

http://www.pixiport.com/haiku-photography.html

http://www.pbase.com/lookheretitia/photo_haiku

LessIsMore.png (142.82 kb)

BigUpFrontDesign.png (782.74 kb)

DeveloperHaikus.png (98.99 kb)


Estimate and Deliver



We've been doing scrum now for over 2 years. It's brought about numerous changes all for the better. It's simply so much better than waterfall it's night and day.

But there's something I feel we've overlooked or misunderstood or just simply isn't right. The core purpose of the team seems to be simply Estimate and deliver. We tend to be presented with solutions or if they're problems there's a steer to a particular solution. This isn't to say we don't adapt when things don't quite work out how they were intended we do, but we try and stay on the original path as close as we can.

Customer focused or Customer focused

We all agree that it's vital that businesses be customer focused. Every course you can go on stresses how important it is that we do what the customer wants. Internally this often translates to a business customer from another department who we're trying to deliver business value to. But what about the end users, your companies customers what about them? Business customers tend to have a target or some goal that they must achieve. They become the teams Product Owner and off we go to solve their problems. Only are we losing sight of the end users goals and motivations?

Problems and Solutions

One of the problems we often face as a team, is that the product owner often comes with what is in effect a solution, which we then need to implement and deliver. You could question whether the problem is a concern of the team that are implementing the solution. What generally transpires is that a strategic direction is set. Then various people discuss what can be done to progress in that direction. Goals are set vague solutions are formed. People often have to go through considerable effort to get an idea through to the point where it's brought to the delivery team.

Then the negotiation starts on how the solution be implemented. Compromises are made on both sides in the name of lowering cost and risk whilst also delivering the solution as quickly as possible. It may be that when the originator of the solution sees what their ideas has morphed into it's unrecognisable to them. It may be better it may be worse, but certainly it won't quite be what they envisaged.

Inceptions and Interactions

We've found that holding an inception for any large piece of work, has real benefits. Firstly it conveys the vision and there within the problem that we're trying to solve. Then everyone's freely able to ask questions to probe the problem domain and suggest solutions. It may be that a solution has already been decided upon, so really they whole inception is really just to bring the team onboard, but it gets the team buy-in which is all important when it's the team that will be delivering this solution.

Unfortunately inceptions don't seem to happen, for what could be termed as regular small changes, or quick wins. It tends to be an endless sea of little changes, with some benefit and even completely logical thinking, but teams morale dips as they're simply not involved in the problem solving. It's not their solution. They're there simply to estimate and deliver.

Have Vision

The answer here is to have a vision. If people are bought into the end goal and they think that this move will head in the right direction to meet that goal, they're more forgiving of not having had input into solving the problem. But be sure to be open to everyone's ideas about how best to achieve the vision.

 

 


Search

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2014