Bespoke Development

To make the case for bespoke development. There are a lot of benefits, your directly attacking the problem you have, directly and precisely. You are not using a hammer as your only tool sometimes you need a spanner.

Agility – Its lighter and possibly more agile as your development can be adapted to suit your goals as they change and develop.

Speed and efficiency – you can spend a lot of time bending an existing package to your will. To the point at which you almost break it.

Faster – often your not carrying a pile of *features* which you never wanted but got as a side effect of the package you adapted.

Easily adapted – more easily adapted with the kind of features that come up client demands, specific legislation or business focus changes.

Intuitive – usage can be designed to flow in a way that fits with existing systems of thinking and terminology so it becomes a lot more intuitive.

Unique to you – hopefully your organisation does something unique, your competitors can also use off the shelf software so are you removing a possible advantage over them by using the same.

Directed – Start with what you want to do and go from there no compromises.

Licensing – you own it a bespoke development is generally going to avoid on going licensing costs that may be associated with existing packages.

So for your untypical problems and challenges perhaps you need a untypical and bespoke solution.

Cyberdojo

Went to a cyber dojo last night at SyncNorwich run by Jon Jagger who had come all the way from Somerset. Its quite an interesting idea you pair up on tasks and just practise. You can give it a go on Jons site here. We paired up on java exercise which was a laugh as Chris and I had no experience in java at all, so we spent quite a lot of the time working out the syntax.

Jon was more focused on the how and why of the process, not writing more code than you need, working together. He summed up and you could see in the review at the end different peoples approaches and stuff like the number of tests each pair had written. Their patterns of test fail/passes and each pairs process step by step.

Jon was saying that some companies had used as part of an interview process pairing there regular developers with candidates and rotating partners gave the candidates a good idea of the company and the people. On the other side the company gets a good idea of how the candidates think and how they are to work with.

Jon started off by asking who used to code when they were kids was it fun – lots of hands. Of those of you who code for money now when was the last time you wrote coded for fun? not many hands. Bit sad really, hopefully cyber-dojo could bring back peoples Joy in Code.

Rereading Extreme Programming Explained

extreme programming

I’ve been rereading “Extreme programming explained” by Kent Beck, It is quite interesting to go over ideas. I’m sure you could use the basis of the ideas in many industries. You don’t have to take all the ideas just grab those that will work for you. So anyway this is what I took away from it on this reading.

Quality

Do things in the best possible way you can. Doing things at lower quality will only bring you technical debt which eventually drowns you. High quality wins trust and its just the right thing to do. Although it may take longer now the alternative is a future of plugging holes in a leaking bodge built ship.

Short Cycles

Try to keep producing regular improvements incrementally. Big bang ‘look at this finished thing’ never seems to turn out quite how you hoped. Its good for your happiness too as it makes everyone feel like they are making progress. You go home happy, happy bunnies do better work and cope better with the really depressing radio news as they go home.

Incremental

You can always improve stuff ‘refactor’ it in computer speak. It only needs to do ‘a’ ‘b’ ‘c’ now so only build something that can do ‘a’ ‘b’ ‘c’ now. You can always add the ability to do ‘x’ later.

Your trying to build Minimum Viable Product if you try and guess what the requirements for feature ‘y’ will be along time ahead you will probably be wrong which means rewriting ‘y’ anyway. If you build more you have to be careful your not going off on one, you love these new features but the client couldn’t care less.

Testing

Testing Testing Testing and automatically. Testing is dull. Automated testing is less dull. If you have a big set of tests that you can run quickly on a project it can save you time and help you sleep. You don’t want to be lying in bed at night worrying about someones website. It just winds you up. It also helps when you refactor as you can tell that your system is still holding together.

Estimate based on prior experience

Not ideal world estimates, maybe when you do that thing or that similar thing again it will be a lot faster, but probably it won’t. Its probably better to use your last experience of doing this thing to estimate how long it will take to do it now. Hopefully you can refine your estimates so that they become slightly more accurate each time you do them.

Simple

The best way is the simplest way, you will be able to understand it in six months and so will anyone else working on the system.

bleeding-edge