programming just isn’t that hard!

Programmers at times can take themselves, and their abilities, a little too seriously. The fact is that programming, in general, is just not that difficult. Sure, there are parts of it that are tricky but, at the risk of over generalising, the capabilities required by your run of the mill programmer are not that high. Are you sure I hear you say?

Well plucking figures right out the air I’d say that around 90% of applications involve a simple CRUD model. So what we are essentially doing is gathering data, processing data, and writing this data to the database. Two-thirds of this process is pretty simple, i.e. gathering the data and writing it to the database, this leaves the possibilities for hardness in the processing data phase.

Again in most situations the processing of data is pretty simple with no complex db manipulation or algorithmic mind games. Consider your typical web application for example. The processing of data is minimal, with little to no algorithmic work involved at all – I mean with Twitter there is literally nothing to do. Google on the other hand has lots to do: it has to make those search results shine. This is not to say that developing Twitter is simple, as the scaling issues will make your head hurt. However, scaling problems are only going to affect a very very small number of sites out there, but due to their ubiquity they are the ones we hear most about.

If all this programming nonsense is so easy then surely it’s difficult to make bad software?

Nope. The fact is that the only people who care what the code looks like are other developers. The code underneath could be shitter than an incredibly shitty shit and the end user wouldn’t know. As long as it carries out the task that they require the software to do, in a reasonably efficient and user friendly way, no one really cares. Oh apart from other developers.

Obviously nice structured code, that is easy to understand, free of bugs, and a maintenance dream is a good building block. However, it is by no means a guarantee that you are on to a winner. Marketing, user experience and coolness are all equally important, actually, they are probably much more important. I obviously can’t say for sure but I would imagine there are plenty of successful software products that are badly written but tick these boxes – maybe even most successful products, as they are free from the burden of the studious programmer.

So, essentially what I’m trying to say is that despite programming not being that difficult there are many other more important factors that contribute to the success of a software product. Many software products do their job, but the one that will be successful is the one that does it well.

All this is not to say that programming well is not important. On the contrary, it’s important to other developers who you work with and that is not to be underestimated. This is a topic for discussion another time though!

Finally, for those non-programmers out there, don’t start shouting “If it’s so simple why does it take so long”? Well just because something is easy it does mean there are not lots of easy things to do. I mean, hammering a nail into a piece of wood is pretty simple, right? But if I asked you to hammer 10 million nails into a bit of wood it would take you a long time. Remember this marketers and project managers.

strong coupling and web development

We are all well aware of the dangers of strong coupling: for me, the most dangerous being the increased maintenance costs in such a system. Much has been discussed about coupling and measures such as dependency injection are used to help control it.

However, as far as a Google search leads me to believe, but I didn’t search too hard, not much has been said about the strong coupling that can exist between HTML, CSS, and JavaScript files. Maybe I’m doing something wrong, or at least something different, from others but many times in recent weeks I have found that the dependencies between these files can be rather tight and restrictive.

To understand what I’m talking about, let’s take a look at an example. Consider the following snippets of an HTML, CSS, and JavaScript files respectively:

1
2
3
4
<div id="main_wrapper">
    <h2>Header</h2>
    <div id="content"></div>
</div>
1
2
3
#main_wrapper {
    color: #FFFFFF
}
1
$('#main_wrapper').attr('color', '#000000');

As you can see the id is referenced in at least three different places. Well so what?

The problem, as I see it, comes from the fact that it is more than likely these files will be maintained by different people. For example, a designer is likely to maintain the HTML and CSS files and a developer the JavaScript file. In the days before JavaScript proliferation, this maybe wasn’t such a problem. However, with the rise of jQuery and its awesomeness the landscape has changed a little.

In fact, jQuery actually compounds the problem, as we have all become accustomed to seeing JavaScript code littered with things like $('#main_wrapper'), i.e. CSS selectors are referenced throughout the code base. What this means is that when the designer changes the structure of the HTML file, or the class names and ids, it can have unexpected side effects.

The easy (part) solution to all this is that when you create ids and classes you never change/remove them or their container – or at least you never change them without searching globally rather than just locally. I’m not sure how restrictive this is though, maybe those with far more experience of this than I do can offer up some more constructive thoughts? Are designers are just not used to such constraints? I dunno?

To me it just seems like a hassle having to keep track of selectors, ids, and classes in so many different places. It seems to go against the spirit of good programmer where we try to localised any side effects when changes are made. With the above way of working this doesn’t seem possible – and combined with the divided level of responsibility between designers and developers, I imagine this causes an increase in the number of bugs and also in the cost of maintenance.

Maybe others don’t see this as an issue at all? Maybe I’m doing designers around the world a disservice? You decide.

At the moment I can’t offer up any better solutions, as I have not really thought about it too much yet. When I do though, I’ll be sure to report back 😀

iterative development

We’ve all had it drilled down our throats that development should be completed in short-sharp iterations. “Release early and release often” – no agile developer gets up in the morning without repeating this mantra to themselves before they reach the sink. However, surely it’s important to realise the difference between “Release early and release often” and “Release utter shit early and release utter shit often”.

Who really wants to use an application/toolkit/library that has so many bugs in it that the user experience is dreadful? Surely users would rather wait a few more weeks for something that is, in a sense, polished? I mean we’re not talking Microsoft Vista style release cycles here, but quality control consisting of a little more than running a set of unit tests would be nice.

So what has prompted this minor rant? Well Firebug unfortunately. I hate to criticise it because it’s free but the bugs I find in it are getting worse and worse. The most recent one being that the continue button no longer works in the latest release (1.4.0b10). Sigh. However, open source or not, my feeling is that if you choose to do something then do it properly or not at all.

Anyway. Regardless of the product, it surely makes more sense to sacrifice your release schedule a little for some real testing and bug fixing? For commercial products a bad user experience is going to make a sale difficult both now and in the future. Being first to market is one thing, but it’s far from being the only (or even main) contributing factor to a products success – Google and Facebook being good examples of this.

So is it possible just to have a little common sense about all this and maybe restate the mantra as “Release quality early, release quality often”. It can’t be that hard, right?