eDiveSoftware blogs

I live in a curious technical world that blends some interesting differences.

Since 1996 I've been involved very heavily in software development for various companies gradually increasing in my knowledge and technical abilities. Also since the late nineties I have been learning to dive and getting more mileage under my belt there. For my day job now I am an Enterprise Data Architect for a decent sized DotCom. eDiveSoftware is my side business and hobby. It's here to allow me to give something back to a major part of my life that I am passionate about, but to also keep various skills fresh and learn new ones.

For software development or IT in general we can take advantage of Moore's law (which governs the speed improvements for microprocessors). For diving, it is all about Boyle's law (which describes the inversely proportional relationship between the absolute pressure and volume of a gas if the temperature is kept constant within a closed system - thanks Wikipedia for the description - phew).

For data architecture (and working with data in general) we have Sod's law. I'm pretty sure that you can't get data wet so Boyle's law doesn't apply here. Moore's law doesn't help as it doesn't applying to spinning disk (although solid state storage is the future and a game changer). Sod's law is the more interesting as it can have different consequences on the other two fields. It's bad in all of them as you would expect.

In software development there is a 'reasonably' new methodology of developing software called Agile

and it tries to bring forward mantras such as 'Responding to change being preferred to Following a plan'. It's this that got me thinking about the two technical worlds I spend my none family time in. When diving you quite often hear things like 'Plan the dive and dive the plan'. It's a major part of what we do here at eDiveSoftware, but it doesn't have to be rigid. So we have two different approaches to doing something. One where we think out a detailed plan and try and stick religiously to it and the other that suits adapting and changing things as we go. Both in their own respects suit really well but how would each suit if we swapped them around ?

I have to be totally honest here. When I first worked in an Agile development environment it was shortly after having come from one (writing software within the motor trade) that totally winged it (and consequently made a right royal mess on occasions - something I fought against for my time there). Agile is NOT this. I've become a convert over the last few years and whilst I don't develop software for a living these days I work within an IT department for my day job that is making some seriously good moves with this. I try to be an Agile Enterprise Data Architect which is an oxymoron I admit, but something I am determined to do.

OK, let's take software first. If we approached it as a 'typical' diver first and foremost we would have to do some pair programming as divers tend to dive in pairs. Redundancy would be something that you would expect to have, so we would need x2 computers per diver in case the first one broke (enter the world of technical diving). If we had a new computer we would only want to introduce one new part at a time (such as a keyboard) because adding monitors and a new mouse together only tempts fate. We could add the mouse in on the next project (after a suitable break for a burger which admittedly can easily apply). By the way, if you dive at Capernwray (www.dive-site.co.uk) I can heartily recommend the burgers. I jest of course (about the diving bit) but it is difficult to take a divers approach and apply it to writing software.

If someone tried to change the plan of work this would only be acceptable if it was more conservative than the first plan. If not, we would want to bin the plan completely saying that it wasn't a good day to code therefore heading off for a burger was the safest option. If three things went wrong, our superstitions might kick in so we would then turn off all 4 computers and walk away as we have pushed our luck too much for one day. Quite obviously this approach could soon get silly.

As a side thought, a DBA would quite likely be the one facing up to a shark and telling them to bugger off as it's their beach :-)

A developer that is used to winging it and is now taking up diving and taking the quick response approach to stuff with minimum planning might well throw themselves in the water without checking that there is something to breathe from as that comes in a later part of the project. Ok, so they got wet and didn't end up diving. So they now promote the need for kit into next project. Erm...the developer can't dive now as the man in charge of the kit didn't have everything in stock and on site ready for them when it was assumed that it all appeared by magic.

An Agile developer going diving would take the approach of planning enough of a dive but have the knowledge that more dives could come along later that day

and they can be planned at the right time. No-one ever dives exactly on the plan that they intended so being able to re-plan at the end of the first dive can help ensure the safety of the next dive (and so on). Instead of taking an approach where the entire days diving is planned out the first dive might be planned in sufficient detail but then the subsequent dives would be re-calculated as needed. We can't predict just how long it takes to off gas, cook the burger (not a euphemism by the way), get a drink and check in on Facebook before doing the next dive. Being able to re-plan dives throughout the day is a very sensible option. Hey, this is where the shameless plug for eDiveSoftware comes in. It's my website so I won't feel too guilty. Give our software a try and have a look at planning subsequent dives on the same day.

The 'Agile' diver would be able to adapt during the day and make the most out of it.

It looks like we can learn a lot from being more flexible. We will probably get more out of the day by doing this.

OK, so knowing your field and limitations is definitely something you want to do, but there are a number of approaches to doing things. It's amazing how many divers you see sticking religiously to the spot on a 5m safety stop. Top tip here....you are allowed to swim along at 5m ! You don't have to keep the same lat/long you know !

Ryan - One of the founders of eDiveSoftware Ltd