A relaxed attitude towards the pragmatic delivery of 'okay' software

I've not been coding in my spare time much the past few months, being seriously busy for a client - but the past couple of weeks has seen me pick up a project of mine that I started a few months ago (HoverBattles) and start pushing to some level of completion.

This has been an interesting project for me, not least of all because it's written entirely in Javascript (WebGL + JS, NodeJS and CouchDB) but because this time I made a real effort to drop any up-front 'zomg my code must be perfect' aspirations from the get go.

What does this mean? Well I pretty much decided that technical debt should not be something to be overly avoided, overly organised code-bases stifle creativity and I really just wanted to deliver something.

I also knew that as I learned more about effective JavaScript that my opinions on the 'best way to achieve things' would be changing about 20x more rapidly than it does when working in an environment I'm heavily used to, and trying to constantly maintain code at some mythical standard would prevent me from actually delivering

A couple of months later how does that leave me? Is the code-base a huge unmaintainable mess? I would say no - it is not.

There are messy bits in there but they're largely on the periphery. An avoidance of up-front framework/empire building has allowed me to be morally flexible with regards to where I put new code to Get Cool Stuff Done, and a healthy concern when going over pre-existing code to add something new has led to some easy wins when re-factoring around the pain points that naturally emerge.

I don't think that I've taken a cavalier approach to the project - at a macro level it's quite well structured, and for the most part there is a clean separation between the different sub-components that drive the system. In a code review there are bits I'd have to apologise for but even in projects with the greatest amount of technical debt avoidance this has been true.

There are some problems with the messaging/multi-player side of things, complex work-flows have emerged as a consequence of the individual components receiving some input, doing something and raising some output in orders that I did not pre-plan.

This has been made more complicated by the fact that some of these components only exist on the server, and yet the events they raise are still sent to the client because the client needs to react even if it is not the one doing the critical thinking.

This is an example of what I have come to classify as a real problem - that is, it is a problem that is naturally occurring and isn't one I have constructed to satisfy the whims of my inner Powerpoint Architect.

When I think of all the things that we work on in our line of business applications, the efforts we go to de-couple everything so it can be easily tested and maintained, the efforts we go to make sure we have the extensibility points and have our "what ifs" covered, I'm seeing a lot of that in a new light as this project goes on.

I don't think a lot of our 'units' in our LOB world are really units at all, they're fractions of 'units', and it's only as part of a more complex interaction that things get interesting and worth spending time fussing over.

Even those seeking to do more vertical testing of a unit within their system (across several internal components) aren't really testing anything meaningful, they're not really spending their time on anything really meaningful either - I wonder if we do a lot of this stuff just to make our jobs more interesting because LOB apps are at a micro-level... quite boring

Anyway I digress, a response could be that some of that rigidity and forward thinking is needed because we have more than one soul working on these projects and if everybody took the cavalier 'get it done' attitude we'd end up with a big mess right?

I'm not convinced - I think that if you have a team that can actually communicate and react to problems as they arise that a good momentum would still be possible, a lot of the technical solutions delivered in these LOB apps seem to exist as a way of avoiding the need for communication and I'm beginning to think of that as less okay than I did

I'm also beginning to think that a concentration on these things causes bigger balls to be dropped. There is little point in arguing over patterns if you're going to forget to apply sanitisation to user-provided input for example - or suitable defensive mechanisms against things that might go wrong (as dirty as that might make some of your code).

Going back to the whole CQRS thing as that was the topic of the last post, this ties in well - those things exist as solutions to complexity that already exists - not as ways of creating complexity that wasn't there before. Technical solutions should be avoided unless they're actually delivering the necessary value.

Random blathering I know, I'll actually start talking about the tech in the game soon I think, it's getting interesting and I think there are some things to say about it