jump to navigation

Friday Philosophy – Early Mistakes Uncorrected Means Poor Final Systems August 13, 2021

Posted by mwidlake in Architecture, development, Friday Philosophy.
Tags: , ,
4 comments

A few days ago I fitted a sink (hand basin) in my garage. Bear with me, this IS related to I.T.

It’s maybe is not so clear from the pictures, but that sink is at an angle (see the spirit level in the second shot, that bubble is way over from being in the centre), leaning back towards the wall on the left. And the splash back is also not straight, it is a good 5 degrees from the vertical. I’m pretty good at DIY – putting up shelves, building cupboards, fixing furniture, building the odd bit of wall, erecting & insulating sheds (which I take power and lighting down to)… And I am very, very meticulous about things like getting things straight and level. As I progressed with the job of putting up this sink and reflected on the process, it so reminds me of several application development projects I’ve been involved in (or was brought in to help crowbar back into shape)

Where Did I Go Wrong?

I’ll add some pictures to the bottom of this blog, but for now I’ll just describe what happened. When I offered up the sink to the wall I realised that the pipework (put in by competent builders but with no real consideration of my planned improvements) was exactly where the sink should go. And I also realised that even if the sink was put higher (way too high for me) or lower (well to low for a normal heighted person) the pipework would still be an issue. Also, the back wall is not quite vertical and the two walls are not quite at 90 degrees. This sort of thing is not unusual in any building (though slightly vexing in something built only 12 years ago) and to me it’s like the not-quite-perfect situation most application developments start at. You might not be using the best database for the solution, you might have to use a computer language that is not the best but you have staff skilled in it. There will be bizarre parts of the application you are replacing that you have to keep as the end users have got used to them – or even built business processes around and no one wants to change those now.

Good developers and systems engineers can work around such issues. A good DIYer can take into account badly placed pipes and wonky walls. I could have cut out and replaced the pipework – but it would have been a lot of work and I am not very good at plumbing (which is why I use push-fit plumbing: less neat & more expensive, but dead easy & quick). This would be like changing those slightly crazy business practices forced by the old system for ones that would benefit the business eventually, but it’s a lot of effort to change. As for the wonky walls, sorting that out would be like re-skilling or replacing my whole development team to move to better technology – Possible, but not going to happen.

The pragmatic solution was to mount the sink on wooden battens and make the battens thick enough to avoid the pipework and allow me to correct for the wonky walls. A cheap, pragmatic solution to the imperfect starting conditions.

Only, I messed up. I spent hours first doing the extra plumbing work to get an isolation valve beyond where the sink & splashbacks would be (so the water could be turned off for maintenance or leaks), and a feed for the hot water unit to come. Then I failed to plane off the battens for the sink properly and they had to come off and be messed with several times. When it came time to mount the sink, which goes on two metal pegs, I screwed one of them in too high. Bloody hell.

From this point on – I was doomed. I should have taken it off the wall and tried again

I was tired, annoyed. To fix the peg I would have to replace the batten. I did not want to take that sodding batten off the wall and replace it (it had been the hard one to make). It was also the end of the day. So I did a “bodge job” – which means a quick and poor quality alteration to get you past a problem. I packed out the space between one mounting peg and a guessed proper height for the sink. I replaced proper planning and good development with something you throw together at the end of an Agile Sprint, so I could meet my objectives and go home.

The next morning I realised the sink was more than a little uneven – but I decided to continue. And that was it, I had messed up the whole job. In my head I thought I could modify the upright battens, get a little leeway with the tiling and grouting and make up for the “bodge job”. I won’t bore you with the full details but I was so utterly wrong. What would have been two totally square and vertical battens for one splashback and a pair of slightly trimmed for the other turned into endless alterations and re-working, especially as towards what should have been the end of the job, it was obvious the tiles were going to look awful (good tiling is all about straight, parallel, horizontal, well squared lines – they magnify imperfections, of which I now had many) so more reworking was required.

If I had fixed the sink mounts first thing that morning, I think I would have finished the job in that same morning, not one and a half days later.

It’s Not The Starting Conditions, It’s The Cutting Corners

The more I have thought about that sink, the more it echoes what I’ve seen in the world of computer application development.

Many times, when the development of an application has gone wrong, I hear people blame the starting conditions. “We had to use Java Struts” or “The analytics team demanded they could query anything” or “We had to make the system talk to the old warehouse system on Informix” or whatever. I doubt these starting conditions were really a big problem, you knew about them and your design should have taken them into account. A good designer will plan around them, a good developer will code in an interface, a good DBA will add in the required indexes.

Not properly planning the system or not prototyping the solution will invariably lead to disaster. In my sink scenario, that would have been the case if I had not used my experience and thought about the long term and decided to try to attach the sink to the plasterboard walls directly, just under the pipework. I’d never have got the tiles on and the sink would have fallen off the wall very soon. I’m not saying you don’t see this failure to plan upfront in application development, it has sadly become more common. Too many places think “Agile” or similar is just hacking the system together and fixing what is wrong. That is, to use a coarse term, just bollocks. Agile only works well (in my experience) when done on top of a very good design, created by skilled people. It’s not easy.

However, the most common cause of issues I have witnessed, by a long way, is that of “bodging a solution” – and again it is very strongly associated in my experience with “agile” done wrong, or even worse the “develop to fail – and then fix quickly” mentality. Yes, you will get something that works. Very quickly. And it will probably be an “uneven sink”. It will do the job (hold water, let people register for an event) but as soon as you try and extend the system, it gets harder and harder and harder. And you spend more and more time working through that technical debt you inflicted on yourself. And the end result will be very much sub-optimal. OK, a simple thing will be fine when put together like this (a shelf to hold photographs, a simple calendar app) but a complicated system like a hospital patient administration system or a fraud detection application, a whole bathroom refurbishment… It’s going to be a mess. I’ve seen and suffered from this cascade of crap so many times over the years.

The whole idea of things like sprints, where you are put under tremendous pressure to just make your bit work, causes a lot of bodging of things. Yes, it does, I’ve seen it. I’m sure if things like code review, pair development, and periods of planning are put into Agile (like they are supposed to be) the bodges could be un-bodged. But I simply don’t see this. And the whole “fail fast and fix” idea seems to me to absolutely guarantee a system covered in duct tape and almost unmaintainable. All for the sake of get it done NOW.

I learnt many years ago in I.T. that it is far more efficient if you fix the mistakes when you first see them and fix them well. Always build on a stable base and keep it solid. Otherwise, as you progress, the pain just builds and builds and builds. This latest DIY experience just hammered it home.

The sink I put up does work. None of the pipework leaks, the splashbacks do not have gaps to let water in, the tiles are aligned (mostly), they are high enough to catch splashes. I know I can put the water heater above it… but it will be higher than I would want and if I do not make it lean to the left, it will make the sink look even more skew whiff. But by the end I put in twice the effort (if not more) than I needed to in order to have a functional sink – and it looks weird.

Do not bodge the beginning of a project, make it right and save yourself from endless pain later on!

For the interested, a pictorial progress of the job.