I’m reading now The Pragmatic Programmer, an all time classic for programmers. For starters, they seem to be the people who coined the term DRY, Don’t Repeat Yourself. Might sound like a minor achievement, but being able to create new words and terms that allow people to communicate faster and better is a big deal. See, now when you hear someone talking about making apps more “web 2.0″ or “harness the power of social media” the bullshit alarm in your brain automatically goes off and you get a quick idea of who you are talking to. Very useful.

The building with the broken window

Very early on the book they talk about something that is very true both in programming and real life. Researchers found that in a building, once a window breaks and it’s not fixed in a reasonable amount of time, the state of said building declines very, very fast. We see this all the time. Whenever something is clean, everyone follows and tries to keep it clean. But as soon as the garbage is left out for too long, people start letting themselves go. Very, very soon, the mindset goes from “wow, can’t leave that rubbish there” to “fuck it, everything looks shit”.

In software projects at the beginning everyone is happy and the rainbow is high up in the sky, but soon enough someone breaks a window. It might be using a literal here cause you don’t have time now to get hold of the config object or making a method public cause it simplifies so much getting the data out of the component, even if that breaks encapsulation.

How to tackle the problem

Fire the developer that breaks the window and doesn’t fix it in time? Too harsh? Is breaking windows a necessary evil from time to time? It really isn’t, but, for the sake of the pragmatic people (tight deadline, client wants this, today I was tired, etc), let’s assume breaking windows in inevitable. I can live with that. But we shouldn’t live with the broken window for too long or devs will start not caring very fast. What once was a nice and clean system can turn very quickly into a mess nobody wants to touch.

If threatening to fire developers might not go down well, what about threatening them with superstition?

Exodus 23:10

And six years thou shalt sow thy land, and shalt gather in the fruits thereof: But the seventh year thou shalt let it rest and lie still

This I think I picked up from Chris Heilmann at StackOverflow DevDays. They say it in the sense that every 7th iteration (whatever long that is in your project), stop coding and clean up. I like it cause I think it brings a good balance between fast coding (I can hack this little thing now, code cleaning comes in 2 iterations) and keeping quality reasonable high.

Also this goes by hand with the idea of the technical debt:

Doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like the financial debt, the technical debt incurs interest payments, which come in the form of extra effort that we have to do in the future development because the quick and dirty design choice. We can choose to continue paying interest, or we can pay down the principal by refactoring into a better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

It’s ok to incur in some “debt” when you kick off the project, same as businesses incur in some real debt when they start. But at some point devs need to start paying back some of that debt or the interest (time wasted dealing with crappy code) grows exponentially.

Bottom line: it’s ok to break a window from time to time, but it’s not ok letting it broken forever. It will haunt you down : )

Keep in mind that these guys are responsible for quite a few things that today we take for granted such us memcached, Unix, JS, Internet, Java, Firefox, etc.

One common thought is that back in the days they used to know in and out every line of code that run on their machines. Most of them spent quite a few years programming assembly and “close to the metal” (aka, the hardware), but today’s programmers “don’t know the whole thing“.

Well, they are right.

I for one have no idea of assembly, machine code or even C. Now, is that good or bad? Granted, the more you know, the better, but most of them also agree that with the level of abstractions that we programmers “enjoy” these days this doesn’t sound possible any more.

For example, think about the abstractions of the typical Flash movie:

Hardware > OS > browser > Flash player > framework of choice > your app here

Now, that’s obviously a gross overview, since we could break OS in (that I can think of, not even sure it’s the right order):

kernel > drivers > window system > graphic card

The thing is, even if you had access to ALL the code running (which most likely you don’t), who has the time and skills to look at it _and_ get job done?

With all those abstractions in place, when something fails good luck trying to figure out where the problem is. Can you be sure? Because even when we find a bug in the player, is that Adobe’s fault? Mozilla? Explorer? Linux? A combination? Very hard to tell, more so when a few of those elements are black boxes (proprietary software, you don’t have access to the code).

Most of those guys wonder about what are the best skills for programmers nowadays. When they started coding, it was a must having very good math skills because of the lack of HW power. They needed to squeeze every single CPU cycle and memory position. Either that or your program wouldn’t go anywhere. We all know that’s not true any more. Is this bad? I say it depends on your work.

If you are building compilers, 3D engines or drivers, then by all means you need to focus on performance and have those skills. But if you are doing user interfaces I bet your users appreciate a hand for design and usability. So, completely different skills needed. The fact that HW has gotten so powerful has lowered the barrier for being a programmer so people with very different skills can afford it now, and I think that’s good. The fact that a designer (and probably even the most advanced Flash “programmer” looks like a designer to them) can build an interface without having to worry about HW, graphic cards and code optimizations is pushing computers to different areas.

Even for developers, the skills you need now are not the skills you needed 40 years ago. They think most developers these days “play Lego“. They mean we build blocks with the frameworks or libraries available, but don’t do any “real” programming. They have a point. But again, is that good or bad? This is classic DRY stuff. Why would I want to code a SHA1 library if there are quite a few there already? Heck, doing so would not only be a waste of time, it’d probably be a security hole as most likely I wouldn’t get it right. Why would I want to roll my own PHP framework if there are a myriad of choices offering DB abstraction and XSS and CSRF protection out of the box?

See, I think what’s important is having the skills to roll your own code when needed and use somebody else’s when it makes sense. And that requires some skills as well. First, you need to be able to identify what’s core for you and disregard coding everything else. Then you need to be able to start using somebody else’s code without having to understand it all, many times only looking at some (often incomplete) docs or API. That require skills. A different type, but skills nonetheless.

Also, obviously with all due respect, I think they miss an important thing. They didn’t start from scratch either. Nobody does.

Standing in the shoulders of giants

For example, very, very, very few physicists question the thermodynamics laws. Very, very, very few mathematicians question Pythagoras. They take them for granted. They’ve been proved. They use them as a base to build on top. Yet, there’re those very, very, very few that do indeed question the core laws that everyone else just “use”. It’s their job challenging those laws, otherwise completely accepted, and put them to the limit and analyze them with modern eyes.

Why we don’t have similar laws or universal truths in computing? Well, for starters computers are what, 50 years old? 70 years old? 80? Physics and maths have been around thousands of years. Even if you could compare both worlds, the rules of the “computing universe” have been created by human beings whereas the rules of the Earth just are. Those rules haven’t changed since the Big Bang, what changes is our understanding of them (call it physics math. chemistry, whatever).

As I was saying, quite an interesting book. One of those you can re-read in 2, 3 or 5 years, still enjoy it and still learn from it. Go read it!

So, when I read this review on Slashdot about the book Intellectual Property and Open Source, I thought I’d give it a go. I thought: “let’s get better on what I hate the most”.

It’s kind of ironic that the book starts with IAAL (I am a layer) but very quickly says something like “whatever is written here shouldn’t be taken for granted, go and check with your lawyer” which is exactly the same warning all the IANAL statements begin with.

The first part of the book gives a background about where IP comes from and why it’s good (or was meant to be good) for society. It also covers differences between patents, copyright, trademarks, trade secrets and all the legal terminology crap.

Then continues with examples such as:

* If you write code for a company, who owns the rights of that code, you or the company?
* If you write your own project that has nothing to do with your current job, could your company claim compensation?

You would be surprised with actual cases and how they ended up. I haven’t even finished the book yet and I’m sure I’m going to find even more interesting stuff.

So, copyright, lawyers, laws and all the crew aren’t going to go away just because we don’t like them. Let’s try to learn how to use them in own our benefit.

Cheers!

ps: Grant Skinner wrote not long ago a very interesting post about licensing source code, give it a read and also to the comments. Interesting stuff.