software engineering

Rapid releases killed Firefox’s reputation

Via this LWN post I came across a very insightful blog post by Brian Jono, one of those many people who develop Mozilla Firefox. In his blog post Brian talks about Firefox’s rapid release cycle and how it drove a lot of people to Google Chrome. There’s nothing new to that. But Brian’s post is a must read for anyone involved in software development – there are several lessons to learn. Here are a few bits that I found interesting.

On updates in general:

I’ve been thinking a lot about the fundamental disconnect between the developers and the users. I think it comes down to: Software developers have a perverse habit of thinking of updates/new releases as a good thing.

It’s hard to convince a software developer otherwise: their salary depends on outputting a constant stream of updates, so of course they think updates are good.I used to believe it. Only after I heard from dozens of different users that the rapid release process had ruined Firefox did I finally get it through my thick skull: releasing an update is practically an act of aggression against your users. The developer perspective is “You guys are going to love this new update we’ve been working on!” The user perspective is “Oh god here comes another update, is there any way I can postpone the agony for a few more days?”

On changes to the user interface (UI):

So many companies release updates which radically change the interface for no significant gain — they seem to be moving sideways rather than forward, changing things around for the sake of change. Maybe their UI designers are bored and need to do something to justify their jobs, I don’t know. After years of aspiring to improve software usability, I’ve come to the extremely humbling realization athat the single best thing most companies could do to improve usability is to stop changing the UI so often! Let it remain stable long enough for us to learn it and get good at it. There’s no UI better than one you already know, and no UI worse than one you thought you knew but now have to relearn.

On competition-driven development:

I have another theory, too: When software companies get to a certain size, they start taking their users for granted. They start treating their users as pawns in a battle against some other company. Faceless millions. Gotta copy everything the other company does, or risk falling behind. So they end up doing everything the other company does whether the users want it or not, and probably doing a crappy job to boot.

On user loyalty:

Software companies would do well to learn this lesson: anything with the phrase “users love our product” in it isn’t a strategy, it’s wishful thinking. Your users do not “love” your software. Your users are temporarily tolerating your software because it’s the least horribleoption they have — for now — to meet some need. Developers have an emotional connection to the project; users don’t.

All software sucks. Users would be a lot happier if they had to use a lot less of it. They may be putting up with yours for now, but assume they will ditch you the moment something 1% better comes along — or the moment you make your product 1% worse.

There’s more. Just read the whole thing, it’s well worth it.

Software developer’s worst enemy

Coding Horror has an insightful article on the software developer’s worst enemy.

[…] the real problem isn’t the code. The code, like a newborn babe, is blameless and innocent the minute it is written into the world. Code isn’t our enemy. You want to see the real enemy? Go look in the mirror. There’s your problem, right there.

As a software developer, you are your own worst enemy. The sooner you realize that, the better off you’ll be.

I know you have the best of intentions. We all do. We’re software developers; we love writing code. It’s what we do. We never met a problem we couldn’t solve with some duct tape, a jury-rigged coat hanger, and a pinch of code. But Wil Shipley argues that we should rein in our natural tendencies to write lots of code
[…]

There are quite a few things which seem obvious, that you can’t really disagree with, but which I also didn’t define or form on my own for some reason.

Project management tips from Linus Torvalds

Linus Torvalds shares some of his thoughts on software project management in this interview. I have two favorite bits in there. One is on the obsession of the code quality control:

“The other thing—and it’s kind of related—that people seem to get wrong is to think that the code they write is what matters,” says Torvalds. Most software development managers have seen this one. “No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it.”

Just a few years ago I would have completely missed this point. Or argued passionately with it. But not anymore. After spending the last few years working with very dynamic software projects, I realized that no matter how much effort you spend on the code quality control, it will still degrade with time. And even if it becomes horrible and hard to look at, it will still work and you’ll still be able to maintain it. But the time and effort that was lost would have been so much more useful in supporting user requests and improving their experiences.

Even knowing this now, I am still a slave of my habits. I still need to control myself, set tight deadlines, and learn to ignore a lot of things that would have caused me a heart attack back in a day.

The second point that I found interesting in the interview is similar.

I also asked Torvalds about Software Configuration Management (SCM) tools like his own Git version control system. He replied, “I don’t think tools are all that fundamentally important.”

“Now, what is important is that there’s a good workflow for the project, and tools can certainly help with that,” said Torvalds. “But most projects don’t necessarily really need tools. There’s a lot of projects that simply don’t have enough changes to really require any tools at all for their work flow; if you only have a few hundred patches per release, you can maintain those just about any way you want, including entirely by hand.”

Again, a few years ago (and even sometimes now) I would argue and fight for the perfect setup and ideal toolbox. These days I seem to care less. As long as the work is being done and the project is moving on, I don’t really care which tools are being used. I have my preferences, of course, and I would try to push them through to be used by majority of participants, but I am much more relaxed on this subject than I used to be.

One other thing that I wanted to mention is the difference in perception. In Linus’ world, it seems, changes are always distributed as patches. To the effect that it would even be considered a specialized tool – everyone is using it. And I understand – all of the people with who he works are very experienced technical people and there is indeed no other way. But for the rest of us things aren’t as rosy. On several occasions I worked in a team where people weren’t using any tools. Literally. They had no idea about patches, diff, scripts, merging, version control, any of that. Changes in those projects were maintained by hand. And there would be nothing similar in concept to a release. Which didn’t help.

There was indeed one particular project. Do you know how I remember it? I was at one of those PHP conferences somewhere in Europe. And one of the talks I attended was on how to use unit testing during the re-factoring process. The presentation was filled with examples of ‘horrible’ code which was then surrounded by unit tests and later re-factored into better code. The code that was presented as ‘horrible’ was some of the best code I’ve seen in my life! After the presentation I came up to the speaker and showed him the project with which I was involved, which had some truly horrible code. You should have seen the look on his face… It took him a couple of minutes to compose himself and start thinking on how to work with that nightmare. He even thanked me and promised that we would include some examples of that crap in the future versions of his talk.

My point here is the difference in perception. When Linus says that things can be done without any tools at all, and when that guy talked about horrible code, they both, I think, are somewhat spoiled by their surroundings. I’m sure not everyone even would be able to make sense of a gadzillion tiny little things that Linus uses on a daily basis and doesn’t even consider them as full featured tools. I’m sure not everyone even would be able to read some of that ‘horrible’ code the other guy spoke about, let alone write something like that (I remember it being OOP, with comments, well-tabulated, etc). There is a certain minimum level which has to be there. That minimum level is assumed to be a zero. But it’s not always there.

Software engineering is like cooking

During the last few month I’ve been explaining software engineering to management types quite a bit. Most of the “bosses” that I talked to weren’t technical at all, so I was trying to stay away from famous concepts, examples, and terminology as much as I could. Of course, that required some sort of substitute for concepts, examples, and terminology. I’ve tried analogies from different unrelated areas, and was surprised as how good cooking was fitting the purpose.

Before I go any further, I have to say that I am not a cook and that I don’t know much about cooking. But. I know just about the same as any other average human being. Which, sort of, moves me into the same category with my targets, or “bosses”, as I called them before.

Here are a few examples that worked well.

Continue reading Software engineering is like cooking

Technology related reading – Steve Yegge

I’ve been pointed to the (now abandoned) blog of Steve Yegge way too many times. But for some reason I never read it. Maybe it’s the look of it. Maybe it’s because of the lengthy articles. But that’s a fact – I haven’t read a single post there until today, desipte the URLs being saved in those many places where I look for stuff to read.

Steve Yegge worked for several years (7?) at Amazon.com and last time I heard is still there, being a development manager for internal Amazon stuff. You can read more about him here, if you wish. By the way, he has also started a real blog too.

Anyway, today I discovered his excellent writings. It’ll take me some time to go over all of them, but here are the few really good ones from those that I’ve read today.

The Nonesuch Beast – rant about some irreducibly complex problem domains that people think are “simple”.
Practical Magic – thoughts about what a programmer is allowed to get away with not knowing.
Saving Time – rambling montage on productivity, emacs extensions, and automation habits. MUST READ.
The Five Essential Phone-Screen Questions – an exposition on how he personally conducts the first 10 minutes of a technical phone screen.
It’s Not Software – an essay about differences between traditional software development and creating software services. This one is an absolute MUST READ.

There’s more, of course.