Now, Next – Then Some Sanity

Planning is a powerful tool – but like all tools only when used properly. Like the old adage

If all you have is hammer, all problems look like nails

I think those who’s professions are steeped in planning – many forms of management – tend to see this as the silver bullet.  With genuine intent to solve problems, they start to plan away at the future.

Even a Developer is Tempted to Wheeled the Planning Hammer

Now I cannot blame them – I know when I started as a team lead, one of the things I wanted to do was to give the developers a stable environment – no more of projects being switch in and out under their noses. With my power plans I was going to be able to go to the powers that be and show them what my capacity would be so I could manage expectations etc etc etc..

But then a bit of reality set in.

After slogging over the product road map, and coming up with a cunning plan for the year - taking all the good things into account – deadlines , key man reliance, and cross skilling– someone made a change to the requirements… oh well just a quick adjustment here… and oh – yes I see that knock on… and that one… well basically I had to start from scratch…… ahh look a nice new shiny plan for the year…

“What!” - you want to make another change….. grrrrr…. slog slog slog.

I am sure you see ( recognise ? ) the pattern the emerged.

Lessons from the Hammer Blisters

What I took away from this quite quickly is simply this.. you can only plan for two things

Now
Next

Anything other than that you are wasting your time.

Really think about it. Unless you are in a very remarkable industry, what are the chances that what you are planning to do in 3 months is really going to be what you will be doing in 3 months ? ( 3 is an arbitrary value – pick one relative to your industry )

The real value of planning, as I see it, is not about figuring out an expected end date – it is about trying to see issues that are just ahead so you can avoid them before they get in the way of the people who are actually doing the work.

Any planning that is not looking at what the people on the ground are doing now – or what they are just about to do next.. is well wasting its time – since that will add no value to the people doing the work!

What about my Stakeholders ?

I know what you are thinking… but my stakeholders need to know many months in advanced what I am going to deliver – and if I don’t plan that far ahead, then how can I tell them what they are going to get ?

Well – lets invoke sanity again – what are the chances that your planning that far ahead is actually correct… slim right ? Check your history how many of your plans 6 months ago reflect what you are actually doing today ?

So if the evidence proves that the information you are giving to your stakeholders is going to be wrong – surely you should feel somewhat guilty lying to them ?

However, I agree they do need information – but how about we given them honest ( actually more accurate ) information by not pretending that we can actually plan it.

Looking Past Next

So what is my plan for dealing with people who do don’t operate on the ground ( Upper management ) – and who truth be told really don’t care about now and next –their only interest ( and rightly so ) is Next++

The priority list.

It is common that they are the ones who populate this list, and they are the ones that give priorities to it. There you are done – well almost – you just need some rough BA time guesstimates.

If you have the priority list, and somebody wants to know when feature X on the priority list is going to come out – you simply take project Now time + project Next time + rough guesstimate that your BA would have come up with for each time in the priority list.

So given a reality like this :

Actual Plans ( Project Manager Domain )

Now : 7 days dev left
Next: Feature Y – 2 weeks

Priority List ( Business Analyst Domain )

1 – Widget ( +- 2 months )
2 – Dongle ( +- 3 months )
3 – ThingyWhatsIt ( +-2 months )

If the stake holder want to know when ThingyWhatsIt will go live the answer is 

“( 7 days + 2 weeks + 2 months + 3 months + 2 months ) given your current priority list “

Yes I know that the BA has not really considered the resource balancing between the dev teams and the testing teams, leave, public holidays etc etc etc… but even if they did – all of that would be wrong anyway – why pretend the future is a science when really is it just a guess.

This will at least be a more honest reflection of what you actually know about the priority list.

Multiple Pipelines - scaling

Now don’t get me wrong.. I am not saying that you can only ever plan for 2 things – that would not scale… but what I am saying is that for each team or capability or pipeline you can only plan for what you are doing now, and what you are going to do directly next.

If you want to scale, then scale by creating more pipelines, create a second dedicated team. Don’t just artificially plan many projects ahead so you can cater for 10 interesting ideas.

Now and Next – Up a level of abstraction

Despite my example above having 3 items on the Priority list – I would make the same recommendation to BA’s – only look at now and next.

If I were a BA I would push back against any serious analysis unless I could get a commitment that this is going to fit into one of the pipelines top 2 priorities… because we all know that by time the N months that has passed before anyone actually get to start working on priority No3 there have been many more interesting ideas that have bumped that idea down to priority 12 – and all that work that the BA did was well in effect wasted.

Conclusion

Don’t try too hard to look into and predict the future – the truth is you can’t.

So be honest about what you actually know, and commit your time and effort to work that will actually be done.

Next is far enough away to be hard to get right by its self– lets just stop there.

Protection by Planned Assassination

As companies get larger the need to address softer issues become more and more important – like inter department communication etc – and if you work in one of these companies the chances are you have or will be pulled of into a working group or committee or forum at some point.

Sadly words like - working group; committee or forum – tend to drain the life out of most people – despite the fact that they may indeed be inspired by the intent of the group.. and why?

Well as I see it, the stigma associated with things like this is they tend to just waffle on in hypothetical discussions or just plain neon-blue sky thinking, and in the end can be ineffectual – and in many cases they are exactly that.

How do you protect the integrity of the group ?

My suggestion is this. Up front, set in stone – a manifesto if you will - all the criteria for terminating the group. In fact I would suggest the purpose of the group be phrased in the context of a reason to terminate the group should it fail.

While it may seem like negative thinking to be effectively setting up assassins for your group at the outset – it is one of the best ways to protect the integrity and set the standard early for the rest of the members.

Make sure everyone buys into the termination of the group if it is not showing the value it ought to.

Set up key point to formally assess the group by whoever the stakeholder will be – and get them to answer concrete questions –not just the fluffy are we helping ? Don’t forget like you they may also be taken in by the interesting ideas and discussions “that may come out of it – but when the rubber hits the road – the ideas are a distant memory.

Then, even if you are loving the group and the rich discussion that it may be generating – have the courage to be the first to call the group out if it is failing to meet its objectives.

The Result

A culture where adhoc groups or committees are respected for the self culling attitude.

Now the people who were afraid to join for fear of being sucked into endless slew of “chatty” meetings – you know, the people who would actually add the real value to the group – will then likely join knowing they are free to terminate appropriately.

Abstractions Create Complexity

The observation

Isn’t  it amazing sometimes how the things that we try to do to solve complexity actually add to the complexity – well at least when it come to the effect on the learning curve.

My son has asked me to write him a packman game where it is possible to control one of the ghosts ( basically he wants a 2 player version so I can be one of the ghosts and chase him – you gotta love children! ) – so I thought that this would be a good opportunity to learn some flash.

I came across PushButton Engine which is a flash game development framework that goes some way to making the effort in developing a game constrained to the game domain and not the mechanics of the flash.

An Example

Now using PushButton as an example of what I am talking about, they have the concepts of components - which are reusable behaviours that you can apply to any of your sprites ( which they call entities ).

Now it is not hard to see that any meaningfully sized game will have many many entities and components with relationships between them – which in the end would leave you with lots and lots of repeated boilerplate code to create and relate the entities and components.

To address this they developed an XML format that allows them to define entities and all the components that they use without having to write a line of “code”. ( aside: I maintain that xml or any other configurations like this is indeed code just not the compiled type ).

This sounds like a great idea – and is .. but interestingly it makes it somewhat harder to learn.

If you compare a worked example of a simple PB game which manually creates everything via code to the one that uses the XML, you find the pure code much easier to follow.

Why – simply because in the pure code case, everything that you need to unravel the black magic is right in front of you. In the XML case you have to context switch between the AS code and XML to try and understand a single new concept.

So the technologies put in place to simplify development is in fact they very thing increasing the gradient of the learning curve.

The picture I have in my head when I think about this is to imagine that you have some core technology and think of it as a sphere with a surface area of core API.

Now when you start to build on this technology you start to add new facades and interfaces which wrap your original core sphere. With each of these layers over time you are making your sphere’s surface area larger and larger – and clearly the growing surface area is the required domain knowledge now for your technology.

So what is the lesson ?

Well actually I am not sure - it is just something interesting – but I guess one lesson might be that you should always give new people access to the simple core that you have and then expose them to the cool technologies you have to make thing easier later.

That might be harder than you imagine – given how close you are to your product and how likely it is that you see the wrapper technologies as the real ‘selling points” of your technology.

What does this observation teach you ?

Start a Blog at Work

If you are reading this blog, then it is likely that you already subscribe to the view that blogs can add value.

But have you ever thought about starting your own blog at work.. with the only readership being the people in your company ?

The power of this is that it frees you up to talk about proprietary things that you would never be able to in the public domain – but more importantly it is a powerful way to share knowledge.

I have written before about how different types of mediums change the way that you write and what people expect from what they read.

Blogging is typically a very free form style, and as such is given the latitude to not cover all the bases, but rather to express the spirit of an idea, or just expose enough to get people interested in finding out more. Given this freedom from formal documentation you will be surprised how much more willing people ( you ) will be to share the scraps of  knowledge they have.

Not everyone loves to blog – but many still love to read – you could be the catalyst that starts a knowledge/moral revolution in your place of work. You  don’t need to be the domain expert – just keen to see people learn more. If it takes off the experts will follow and correct you!

I have been doing it at the company I work for a while now, and have seen great results… give it a go and let me know if it is working for you. 

Language Choice is Similar to Choosing a Musical Instrument

Following on from my post Software Development is like Painting I will take the opportunity to make another analogy, this time at a lower level looking at the choice of language in software development.

Is this going to be a blatantly obvious post ?

It does not take a rocket scientist to guess where I am going with this analogy – different tools have different strengths and weaknesses and you must pick the most appropriate one.. See that was easy – all done.

Just kidding… so if that is not really the point, what is the post of this post – well simply that the musical instrument analogy has an interesting aspect to this.

So what makes this analogy interesting ?

Now, while we know that every mature  ( and many immature ) developers appreciate that the different languages have their strengths and weaknesses – these same people somehow manage to get into a “holy war” when the rubber hits the road and discussions start about which language is better.

What is interesting to me is that I have never heard the same “holy war” or “curly brace war” when it comes to musical instruments. People tend not to fight about the fact that a guitar is much better than a piano.

However, there is very much a “curly brace war” when it comes to different musical styles.

So if you are following this highly skilled  progression of logic, you will see that, for some reason, many developers, despite their maturity in many cases, still see language as a musical style and not as an instrument.

So What ?

Well if we could find out why this distinction is not clear, then in theory we could find ways to make it clearer and stop these ridiculous wars, and get on with the job of making great software products ( the music ) – which then should be appropriately debated and fought over.

My Theory…

Perhaps it is simply because, in many cases the line between instrument and music are blurred simply because we tend to have a 1 technology solution for an application – so from the developers perspective that instrument basically is the music.

Now I am sure there are many exceptions to this, but the point is that it is not easy for a developer to seamlessly slip from one language to another, and so makes the barrier to entry much higher for whatever the other language is.

Now imagine a world where is a single file – lets call it TheProgramme.code which had a slew of mixed code.

So there is one method for sending mail that simply uses C# and .net to manage sending the mail, but directly underneath that is a method for parsing some text and well that method is written in Perl for the natural regex. Then there is some bit unpacking which obviously would be done with Erlang a bit lower down etc…

This programme is compiled by a single tool ( which would  just link in all the appropriate compilers at the right time – lets just pretend that is not hard  ).

In a world like this, I wonder if people would not more clearly see that language is simply an instrument, and that the application is the music.

Random Idea Time..

The Problem

There I was the other day using someone else’s thumb drive – so I felt compelled to remove it safely by doing the whole formal approach – which reminded me why I stopped doing it a long time ago ( apart from the fact that I would keep forgetting about the need for it )

It just annoys me how long winded the process is and even when I do do it, I don’t really have a clue what is going on or which one to stop since there are normally a myriad of them at the time

So typically with my own thumb drives I just rip it out and hope for the best.. so far so good… one day I will regret it I am sure.

My Cunning Solution

Why not lets put a button on the thumb drives that will notify whatever needs to know that I am about to take my thumb drive out.

Chances are, if I had that I would ( read as might ) actually use it and save myself the misery that I am doomed for.

Why would it work ?

Good old locus of attention.. when I want to pull it out I am reaching for the thumb drive.. at that point I may notice the button and remember.

Also the devices knows who it is, so there is no annoying guess the right USB device pop quiz you have to get right.

Software Development is like Painting

Okay so the analogy is a weird one, but you will sympathise when you understand that for the last couple of nights ( and the next few to come ) I have/will be painting internal walls.

There has been lots of talk recently in blogs and co-incidentally in a conversations I was having with a friend Suven, about the creative nature of software development – how, as hard as we may try to turn our profession into a science.. it is simply not.

Now, many people have just claimed that it is because our industry is so immature, and it is still building and understanding its self – but I just don’t buy that.

Yes I agree that we will grow as a profession, and develop more mature practices that will help define the profession.. but we will never be a science with repeatability as a cornerstone.

Umm, your title…. painting ?

Ahhh yes.. so how did I get to this stunning conclusion ( apart from just having a gut feel about it, and trying to make it true by proof of repetition ) – I was thinking as I was painting with my power roller :

Many years ago there were probably hard working painters who only had brushes, and had I introduced them to the concept of a roller, they would have thought that the bulk of their manual labour would now be over.

And the insecure amongst them, would be thinking that their days as a painter would be numbered – since the new technology has put quality painting in reach of all.

Then it occurred to me, no matter what technology is introduced to remove some of the grunt work, there is always going to be a element of creativity involved – and element of skill involved, and element of professionalism that I will just never attain only doing some painting every now and then.

Umm, … I am still not getting your point ?

I know it is not exactly a crystal clear analogy.. but lets look a bit closer.

The key thing that struck me, was that while the roller was a great technology to allow me to paint a large wall insanely quickly, and smoothly to boot – there are always those edges that needed to be tidied up that the roller could not do.

At the end of the day all quality work needs the attention to detail that will never be technology-ed out.

Our Industry Operates on that edge.

Software development is interesting in that it is almost exclusive operated on that edge. Even the simplest things we do, require acute attention to detail ( else we get hacked, bring down an entire system, or burn huge sums of money very second it is broken).

Now as much as our tools get better, and our resources expand to cater for many of these finer details for us, there will always be the interface to that abstraction that need to be thought about and used very carefully.

In fact for us, the more tools we have, the more abstractions we have the greater the size of our industry edge becomes – making us less and less of a science and more and more of a creative art.

Summary

The edge work on my wall is average to say the best, and our industry is very much firmly placed in the creative field.

It will never be automated out, and will always require passionate, hard working and intelligent people just to make it work – let alone be great.