As usual, xkcd speaks the truth, the whole truth and nothing but the truth so help me Google.

I’ve witnessed some of these epic workarounds that people invent when they don’t fully understand what’s going on. I’ve invented a couple of epic one’s myself, especially in new programming languages.

One (there are others…) specific example I remember of Epic Workaround Woo By @shawn_hamman was on a loan origination and servicing project many, many years ago in Visual Basic 6. I hadn’t been programming in it (VB6) for very long (at all, would be a more appropriate term) when I started on the project. It was during the ramp up phase and we were busy building a proof of concept to illustrate how the UI was going to function while the company hired the rest of the development team. The ‘proof of concept’ turned out to be the actual product in the end…

You may laugh at what comes next. I’m only a little embarrassed.

There was a requirement for a “combo box” that couldn’t be edited. The VB6 ”combo box”, by default, allows you to enter text or select an item from the drop down. The editable text, in this case, was an unacceptable situation. Not being used to Visual Basic and being relatively new to commercial programming and being pragmatic about software development I set about building a work around for this. I made a OCX component with this editable “combo box” and through an elaborate set-up of triggers, methods and checks made it un-editable. Essentially replacing the text in whenever it changed to what was there before, except when you selected an item which would then… you get the idea.

It did the job ok. Sort of.

The problem was that shortly after that the feature creature got hold of it and the OCX got a built-in label and validation… it kept growing. It was a problem because every time the OCX changed an elaborate update of the entire project had to happen on every developers machine, the old OCX had to be unregistered, the new one registered, Source Safe updated… for every bug fix. It took weeks.

Of course, a senior developer was hired eventually who took one look at my work of art, barked a laugh and pointed to the “list box” control.

Of course, since I can fling a bit of assembler around when I need to, I obviously agree with this chart (…mostly). I think every programmer should be forced to learn assembler when they start out, so that they properly appreciate how a computer actually works… and to scare off the wannabe programmers who shouldn’t really be in the job in the first place.

I’ve never really tried to learn Lisp though I’ve considered it a couple of times. The one thing that puts me off is that any programming language that uses more parenthesis than actual code can’t be a proper programming language.

Also, Ruby? I have one thing to say about that: Python > Ruby. That is all.

Another oldie but a goody, making a bit of fun of the software development process. Mostly the massive amount of miscommunication that goes on during the software development process. And there always is… massive amounts. On the other hand, you must consider that from a developers point of view, user’s don’t speak a civilised language anyway…

Basically the only way to ever avoid disaster on a software engineering project is to have awesome developers who can roll with the punches. There are always punches and the ones who can’t roll and accommodate break and broken developers don’t develop awesome software. They definitely don’t release awesome software.

Flexibility in your development team, then, is generally your only hope of putting out passable software in a reasonable time.

I am currently faced with a situation where, in infinite wisdom, previous occupiers of my position made the incredibly enlightened decision to a) run our production environment using a custom compiled version of PHP and b) run the staging environment NOT on that same custom compiled version of PHP.

Now, you may be thinking that there isn’t any real issue with running a custom compiled version of PHP on a production platform since this is done quite regularly. I have a different opinion.

Compiling PHP yourself means you have to re-compile PHP yourself when you need something new. Re-compiling PHP on a production platform with many millions of page views a month is a tricky task, takes a lot of effort and to be completely frank, is a real pain in the arse when the shit inevitably hits the fan. Shit has a natural attraction to fans and compiling the interpreter your entire system depends on magnifies this attractive force.

I have just invented an equation to calculate the strength of the attraction that shit has to the fan in front of it: The Shit Attraction Force (F) is equal to the number of servers in the cluster (S) multiplied by number of page views per day (V) raised to the power of dollars generated by the system (d) in a given month. F is measured in F-Tons and is magnified by the number of configure arguments you use before you re-compile. You see what I mean? This kind of force is comparable to the force that is currently pushing the galaxies in the universe apart. Freaking vast, is what I mean.

All of this can be avoided by using simple standard packages. I have not yet come across a ‘production’ requirement for normal web development that actually HAS to use a custom compiled version of PHP. In fact, if your requirement is for a custom version of PHP, you should be building your own suite of packages. Always.

In this particular case, I need PDO to work. Simple little package would have sorted that out. As you might be able to tell, this is currently not the case.

Having a staging environment that mirrors production, in this case, would also have been useful.

So, the things we are doing to sort this out basically involves the re-compiling of PHP in the short-term but in the medium term, thankfully, I’ve preempted this situation and have a spare server ready to start the re-load process though which we will damn well move to a pure package managed environment both in production and pre-production and development and on every freaking desktop.

I have two more things to say about that:

May very bad things happen to people who build their own PHP and leave it undocumented.

May even worse things happen to people who change pre-production to be different from production.

Below is the latest in our early morning awesome guerilla games. I think perhaps the moderator doesn’t have a QR code reader since that one has been up for much longer than we though… 10 minutes at the time of posting. Also, they seem to have missed the nice little picture of Yellow HQ… heh.

Kicking ass since '10.

Right, I guess we should get on with the rest of this day now.

Edit: Half an hour and counting, both pictures are still up. I think we’ve found us a moderator that doesn’t know what a QR code is… and may be a little tired because he’s also missed the Yellow HQ picture. Heh.
Read More

It’s Monday. Mondays always lack awesome so we took it upon ourselves to inject some Finda Awesome into it.

James is off today (it’s his birthday vacation day) so we left him a little present on his desk. All over his desk actually. And then there’s the other picture of guerilla awesome. They’re getting good, I have to admit, our pictures were only up there from 8:21am to 8:23am. They’re quick so we’ll have to be quicker… but more on that later.

An insightful comic strip outlining a day in the life of a programmer. It’s almost like the creator of the strip was thinking of @nil_semaj while working on it. Seriously, the resemblance is uncanny…

People who don’t develop software don’t really appreciate the massive amount of frustration that can be caused by looking for a bug that, after hours and hours of looking at every possibility turns out to be a simple typo. It happens. Hopefully not often… and when it does, blame it on bad error messages…