Take Ruby on Rails for example. This used to be the poster child of getting an application up and running quickly. This might be still be true if you have years of experience developing Rails applications but for a newbie, forget it, you are going to struggle. The introduction of the asset pipeline, amongst other things, has made learning how to use Rails a labour of love.

It’s not just Rails though. A lot of the code that you need will already be wrapped up in a library written by someone else. Creating a modern software application is essentially just a case of rearranging these packages into a new unique order. In fact, the need for the order to be unique can probably be dropped.

Using these libraries is good though? Right? I mean we should never “reinvent the wheel”?

So how many times do you find yourself spending more time trying to figure out how the fuck to use some library than if you had written it yourself? No-one really expects there to be detailed documentation, which is just as well, as in general you’d be thoroughly disappointed. Maybe it’s because I’m dumb, but figuring out how to use a library can be a complete time sink. I mean, I hate to encourage this, as it seems like I’m committing a heinous crime, ’cause that’s what I’m told I’m doing, but just write the code yourself if it gets it working quicker for you. Obviously don’t rewrite the exact library that you are shying away from using, that is just stupid, but if you only need a subset of it’s functionality then go for it.

Never forget though, there will be a team of astronauts telling you that’s not what you should be doing. They will be spouting dogma, about this and that. However, if abandoning some well written (and not so well written) rules allows you to create a product that people use and love then tell the astronauts there are people who want to hear their shit on the moon and let them go there.

Back then a PC was the something only the posh kids had. My school was fully laden with BBC micros that you could only use to control some piece-of-shit-circuit-board that you had cobbled together to light up a few LEDs in the form of a traffic light.

I still remember to this day getting my first PC – a (big) Compaq laptop of sorts. It was purchased second-hand from a shop that specialized in guns, knifes and guitars – I still have it somewhere. They probably didn’t even know what it was. When I read stories of people in the 80s having PCs it makes me laugh as, in my world, this stuff was sooo out of reach that you wouldn’t believe.

Still, what would the general public have done with the PC back then anyway (apart from gaming)? The internet was a luxury goods item at this point. Even at university only a few computers had internet access. However, between ’95 and ’97 it exploded. You were faced with a computer lab full of students looking up porn and printing out the pictures (I mean they were not much use unless you printed them out, right)! Those were the days of looking up what you wanted with reckless abandon without feeling that someone or something was watching you – soon to be quashed with the corporate firewall and government legislation. Make no mistake though, we are still in the golden age of the internet. Laws and legislation will likely mean that the freedom we associate with the internet now will not be the same 30 years down the line.

What puzzles me most is how we got by programming without the internet? If tonight I decided that I wanted to learn OCaml to build some super useful web service, then I would start by searching Google. I’d get binaries, sample programs and documentation in minutes. If I had a problem, I could search on Google or ask a question on Stackoverflow. The barrier to entry is just non-existent. I struggle to remember exactly what we had to do all those years ago. It must have been ridiculously hard compared to the present day. But this is good. We got information easily and moved forward. That said, the internet does have its bad points.

We now struggle to get things done because we can listen to music online, watch videos, read blogs, not to mention the ease with which we can communicate with friends using social networks. What the internet gives with one hand it takes away with the other.

I’m often tempted to unplug the router and see how I get on with work minus the internet. Invariably at the last minute though I find some compelling reason to have it switched on, then the thought of uplugging it fades into nothing and time just slips away again.

For the uninformed IT “professionals” that have never heard of Don Knuth this is the guy that brought to us the idea of analysis of algorithms and asymptotic notation (big-O notation), the Knuth-Morris-Pratt string searching algorithm, the Art of Computer Programming book series, the list goes on. However, he is not only an “algorithm’s guy”, he also developed the Tex typesetting system and the METAFONT language used to define vector fonts. So basically he is the most famous computing guy out there.

Knuth is a surprisingly easy guy to talk to. Sure, he can really lose you pretty quickly in a conversation, but he also has some great insights.

Our conversations tended to centre around stuff to do with algorithms. His next volume of the Art of Computer Programming will likely focus on constraint satisfaction problems and satisfiability problems – the former being something I worked on myself in the not to distant past. I asked what he thought was a good algorithm to teach people and he said he thought the biparite graph matching algorithm was a nice one in terms of beauty (he did mention another which escapes me now). Not everyone will find the algorithms stuff that interesting (you should!) but his view of beauty is maybe something more universal.

He also expressed a love for writing code, he said that when he gets up in the morning he thinks about writing code and misses it on days when he doesn’t get the chance. That is pretty cool by me and sits in stark contrast to many academics. I got the feeling that he wasn’t too keen on the “apps” developers as he called them. My guess is that his thoughts lie with more meaningful problems than fart apps – however people download them so who are we to say. Still, there was definitely some lamenting going on about the fact that people use software without ever trying to understand what the software is actually doing. That is, have at least a high-level view of the data structures and algorithms used that make the said piece of software useful. Having this kind of understanding allows you to select the right tools for the job. In my experience people that tend to have this knowledge and understanding are far better developers and is likely why Google, Microsoft, Facebook et al. try to attract developers with this kind of knowledge.

He was telling us that he watched The Social Network on the way over on the plane. He said he thought it was great how Mark Zuckerberg was also someone who just liked building stuff like him – this was something Zuckerberg said himself at Startup School 2010. What is even cooler is Mark Zuckerberg actually sent him a copy of the latest Art of Computer Programming book and asked him if he would sign it for him.

So Don Knuth himself will have long forgotten who I am but at least I will be able to recollect years down the line this encounter with a computing genius.

Personally, I think this might be a good call. How different are the currently programming languages from C? OK, today’s popular duo, Java and C#, have garbage collection and thus we don’t have to deal with those troublesome pointers. Then again, both LISP and Smalltalk have had garbage collection for a long long time. C# has lambda expressions, and other higher-level functions, but then again this stuff was around in LISP since day dot. It’s almost as if the “C-style” languages are battling to catch up with things like LISP – which is a language I’ve never used other than for some emacs hacking. However, LISP has been around since 1959, so why has it taken so long for people to realise that many of its features are incredibly useful? Have we been held back by the fact that most academics don’t really care too much about this kind of stuff, and so don’t push it, and industry is too busy telling us something needs to be done last week?

First, I know that there are academics who do care about this stuff but I don’t think there are enough. And by virtue of being an academic, they are not exposed to many of the problems that are faced by your every-day software developer, and as such, maybe they don’t see the future so well. Thus is it up to industry to innovate at this level? If it is, I don’t see us moving too far forward from our current situation in the next few years. Why?

Well, most small to medium sized software houses are not exactly making money in significantly large quantities to warrant throwing it away on research that some other company making similar software will use to create a similar/better product. So instead of spending money pushing forward the state of the art, you would be insane not to spend that money on making a better product. This combined with crazy schedules, does not leave much in the way of time for forward thinking.

So it appears that we need to rest our hopes on the large enterprises like Microsoft, Google, et al. It’s fair to say that these companies invest a significant amount on money in research, some of which goes toward trying to make programming languages better (F# and Go for example). However taking these two languages as examples we see that F# doesn’t appear to push that many boundaries, and I can’t comment too much on Go, as I’ve not looked at it closely, but it also doesn’t seem to include too many radical switches. Maybe radical does not sit well with shareholders, I dunno.

The thing is, I’m not professing to contain much insight on this either, and I’m not even sure I know what I mean by a radical switch. I just know it doesn’t appear that academia or industry are moving this forward quick enough – if the last 20 years is anything to go by. The only remaining vehicle for change is the programming “community” as a whole, but how much traction we can have is debatable. That said, we do need to move in a different direction, I’m sure of that, and maybe things like multi-core processors may force us kicking and screaming in that new direction. However maybe the problem is even deeper than this, and a switch away from the whole Von Neumann architecture is required. Who knows? Well, I hope someone does!

First, we cover the forced abandonment. This is when you are pushed kicking and screaming into pastures new, whether you like it or not, i.e. the new job. Here, not only is the new language curve ball thrown (viciously), but you also get whole new set of business rules into the bargain. So what do you do? You program the new language like the old one, only translating the syntax in your head. This is not the best way to learn a language though. Why? Well consider those C programmers trying to program imperatively in Java, Java programmers in JavaScript, C++ programmers in Ruby, and so on. When there is a change in paradigm this mapping strategy just doesn’t work – a similar situation exists with languages that contain a more powerful expression set. It also encourages the behaviour where people learning enough to get the job done, without understanding what is really happening, or that there may have been a better way using “unmappable” language’s features. A better approach would be to write something small, and new, that allows you to explore the language’s features. I’m sure most people can think of something they could write. Furthermore, if you can make it useful to other people, or even your new employer, then everyone’s a winner! This is something I touched on before.

For many people though, this is the only time they will ever consider abandoning. This is sad, and a poor characteristic in a programmer. And to be honest, I just don’t understand it. That’s not to say that I don’t accept that people just do programming as a job, then go home and don’t think about it. However, it’s like most things in life, it’s nice to progress?

As a programmer there will also be other signs that the tide is turning, and you don’t have to be too alert to spot these. Previously I wrote “Perl is Dead, Long Live…Perl?” and being a big Perl fan it was sad to see the language apparently dying, so I know what it’s like. Some signs to look out for may be:

• the language features are not moving on (Java watch your back) – the people who created it no longer care,
• the community surrounding the language is dwindling – the people who use it no longer care,
• there is little in the way of choice when selecting libraries/frameworks – the experts have fled,
• other programmers have never heard of it – there is no buzz,
• jobs using it are few and far between – businesses have given up on it, the death kneel.

However, this is all not to say that you give up on your language just because it’s no longer cool – popularity is by no means a great indicator that something will suit your needs. It need not be the case that you give up on your language of choice, instead it could be that you contribute and drag the language forward. But be careful with this one.

Finally, any decent employer will want to see that you are continually developing your skill set – their business needs are continually evolving, so why aren’t you? You are much more likely to land a better job if you contribute to your own education in some way. It looks good and it’s also something to talk about.

So go out and learn something new today, and stop sticking with what you know.

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.

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

I mean, I like to think I’m a geek, sad, but true. However, if the things mentioned in that article are likely to incite an argument in a geek, then I ain’t a geek. True geeks laughs in the face of such insults. So bearing all this in mind I say a real geek is someone who takes offense when:

1. someone states that programming is just a day job;
2. someone tells you they work in IT/computing and they can’t program – this often comes in the form of a third-person telling you their friend works in IT just like you!
3. someone tells you that the technology used doesn’t matter;
4. someone’s role call of programming languages does not extend to at least 4 and they don’t know at least one dynamic language – real brownie points go to those who know a functional language;
5. someone shifts a conversation about programming to something else – oh yes, including girls, well maybe not!
6. a developer tells you they don’t have broadband at home;
7. someone states that Agile development is essentially the same as the Waterfall model;
8. someone becomes a “developer” during a one year Masters conversion course – in particular sociology and arts students;
9. a “developer” tells you they want to be a manager;
10. people don’t think they’re a geek.

There you go, if you don’t agree with these then you ain’t a geek! However, you are at least one tenth of one!

]]> http://equivalence.co.uk/archives/1297/feed 3 http://equivalence.co.uk/archives/1128 http://equivalence.co.uk/archives/1128#comments Fri, 15 May 2009 10:49:12 +0000 Gregg http://www.equivalence.co.uk/?p=1128 I love frameworks. You love frameworks. We ALL love frameworks. As web developers we just can’t get enough of these things. They’re everywhere: from Rails, to MS MVC, to CakePHP, to Django, and so on. I’m so obssessed with frameworks that I spend more time thinking about what one to use than actually using it. But this is not the only problem, as after choosing one, your problems can really start.

On a project that I have been intermitently working on for a little while now I chose to use CakePHP. The reason for this choice? Well first, I had a pretty good knowledge of PHP as I wrote my own little PHP framework when web frameworks were a mere twingle in their daddies eyes. Second, PHP is widely supported on shared hosting – though Ruby is catching up (that said, I’ve experienced some horrors with Ruby hosting). The widespread availability of PHP also means that PHP hosting tends to be cheaper.

Anyway, this is all beside the point. My real issue is with the size and complexity of these frameworks. Just the other day I was looking to do something as simple as validate an input that was supplied as an HTML POST parameter. Pretty simple right? Well it ended up taking me a disproportionate amount of time to do this task.

The first port of call was to find out if the framework itself supported this, which to my delight CakePHP (1.2) delivered on. Now it was down to the trawl/skim through the documentation trying to figure out how to actually do it. I found what I presumed done the task – basically I was required to add the appropriate validation rules to my model. Thus I added the following:

1 2 3 4 5 6 7 8 9

<?php class Section extends AppModel { var $name = 'Section'; var $actsAs = array('Tree'); var $validate = array( 'name' => array('rule' => alphaNumeric, 'required' => false, 'message' => 'Alpha numerics only')); } ?>

Then in my controller I simply called the validate method:

1 2 3 4

if(!$this->Section->validates()) { parent::handleAJAXError($this->Section->validationErrors); return; }

What happened? NOTHING! I passed data that should have failed and it passed. SHIT! I then decided to check to see that the rules were getting parsed so changed the required key in the rules to true, and passed nothing in. Now it worked – it asked me to specify the parameter. My logic was therefore it can see the data and the rules are getting parsed so what the hell is happening!

By this point I had spent quite some time trying to figure this all out. To be honest, I could have written the validation code quicker. So that’s what I decided to do. Yes I reinvented the wheel, it took me around 5 mins, dwarfing the hours I had spent trying to get the stupid library validation code to work. Not only that, much of the supposed benefits offered by using the built in validation code was of no use to me – it wasn’t built around AJAX requests. So what is the moral of this story?

Well it’s read the documentation better, don’t run the most stupid tests, and don’t charge-in thinking you know how everything works! WHAT I hear you say?!

If only I had taken more care when reading, eh the first paragraph, in the documentation I would have observed this:

First, set the data to the model:

$this->ModelName->set( $this->data );

Whoops I never done this. Basically I wasn’t EVER passing in any data to validate, which makes my shocking test of changing the required to true to convince myself the rules and data were being parsed an absolute joke. Rushing in to write my hand crafted code is as bad as the other old chestnut of complaining “there is a bug in the compiler” – c’mon we have all said it The only thing I can credit myself with here is that after a recent 4 week holiday I was stubborn enough to not give up and go back an look at it. Therefore, if there is anything to learn from this experience it’s that before starting something make sure you have taken the time to either read the documentation or listen to those trying to guide you. Oh and have a certain amount of stubbornness about you – not too much though.

]]> http://equivalence.co.uk/archives/1128/feed 6 http://equivalence.co.uk/archives/479 http://equivalence.co.uk/archives/479#comments Mon, 02 Feb 2009 21:12:59 +0000 Gregg http://www.equivalence.co.uk/?p=479 As developers we are often faced with the issue of time vs. quality. Let’s face it though, we could spend forever getting it all just right, from documentation right through to unit testing. However, there has got to be a point when you let it go and see how it flies.

This is particularly true when you are faced with a real-world optimization problem, e.g. scheduling, time tabling, process optimization.  Often with this type of problem it is very difficult to obtain an optimal solution. However, I find the more time you spend on the problem the better you understand it, which normally leads to an improved model.  In turn, the improved model leads to a better solution, or an equivalent solution found in a shorter time.

This begs the question when do you give up and say it’s finished?

To be honest, I’m not sure what the answer is to that. As a developer I want to keep on going, hoping to pull the rabbit out the bag, but as an employer, I just want the thing done good enough to have a competitive edge.

The same goes for unit testing – especially at a startup. In this setting you are NOTHING until you get your product out the door, and until you do, you are hoping and praying that no one beats you to the punch. Some people say that quality shines through, but how bright it shines I’m not sure.  Take myspace as the perfect example. It has no redeeming features - it just got there before everyone else. Does anyone know a band not on myspace though?

However, Google proved that the best product can establish its market regardless of its starting position – I now find it difficult to believe that I thought Altavista was good. It’s important to remember though that for every Google there is a myspace (or the ipod, for that fact) where the first is not the best, but people have invested too much time in their choice to change (or in the case of the ipod, maybe it’s fashion outshining functionality).

So what IS the answer to when is the software ready to go? Maybe the simple answer is “whenever someone is willing to buy it”!

]]> http://equivalence.co.uk/archives/479/feed 0