Tuesday, July 01, 2008

The Problem With Popplers

Today's entry is just a rant about the state of programming in general. That's why the subject line is completely irrelevant. I was going to call it The Problem With Programming, but where's the fun in that? My problem with programming is that we keep having the same endless discussions. These discussions, in my humble opinion, are not really of much consequence. Most of the programming discussions seem to have to do with a) programming language features, b) new and better programming languages, and c) methodology. Hey, this is an "agile" programming blog, right? So I'm already guilty of c. The truth is that none of these things really matters all that much in relation to the giant elephant in the room: Competence. With reasonable exceptions, if you're competent in one programming language, you're competent in them all. Sure, you'll have to take some time to learn the idioms and quirks of another language, but that's fine. Am I really going to be significantly more productive using C# than Java? What about Python? What about Perl or PHP? What about Ruby? Oh, those are boring, eh? Perhaps something like Scala or Lisp would do the trick. Honestly, does it really matter? Sure there are cases where such distinctions do make a difference, but frankly, assuming you've got some kind of reasonable OO language without pointers (I've excluded C and C++ from this discussion), really it comes down to this:

1) Is the inherent performance adequate for your forseeable needs?
2) Is the platform stable?
3) Can you find suitable libraries for what you want to do without re-inventing the wheel?
4) Have you addressed relevant portability issues?
5) Are the available development environments suitable for your needs/preferences?

Really, that's about it. Everything else is just kind of annoying dithering. Sure, with real human languages people have a lot of vested interests, plus there are aesthetic concerns. But programming languages have only been around for decades. Do we really need to have a balkanized landscape in the programming language world to mimic that of regular languages in the real world? Apparently so! As for aesthetics, I suppose poetry written in French can never be perfectly translated into English, or Chinese, or Swahili, and so on. But we're talking about computer programs here. The aesthetics should, in my opinion, be limited to expressing things clearly and economically. Computer programming is much more like technical writing than poetry. If there are real aesthetics to it, then I would say any poetry in programming lives in the realm of algorithms, which are language-agnostic anyway. Then there are the endless debates about changes to programming languages. I had an email discussion recently with a fellow about checked exceptions in Java and how terrible they were. My goodness. If you don't like them, then don't use them. It's easy to dispense with them. It's not a problem. Frankly it's a waste of mental energy to discuss things like this. But that's what people are into these days. Endless onanizing with the latest and coolest language features. Should the language be more dynamic? Less dynamic? Can we write our own specialized Domain Specific Languages? Sigh...

Finally there's the methodology cesspool. I have my own views. The problem is that this issue tends to be at the forefront all the time. Is XP good? Are all XP practices good? Is agile a religion or a con? What's the difference between agile and lean? The simple reality is having competent and motivated programmers is good. Having unmotivated and incompetent programmers is bad. If you have competent and motivated programmers, then a really bad methodology may cripple them, but nothing short of the insanity of the CMM stuff is likely to do that.

CMM level 5, denotes complete paralysis. Levels 2 to 4 indicate various intermediate stages where paralysis is spreading, but you can still ship.
The norm is simply chaos without any form at all: The hack and fix grind. Outside the realm of complete insanity, there are practices that most reasonable people would agree on: Automated tests for regression and quality; using a revision control system; integrating the tests into the revision control system as part of an automated build; planning and designing in some kind of iterative fashion; communicating - you know, like, talking to one another in some way that doesn't involve exchanging 200 page documents. Cooperation - people involved genuinely wanting to help one another reach the goal.

Ok, you get the idea. Beyond that, it's all about refinement. Don't like pair-programming? Fine. Prefer writing automated tests after you write the code for a particular feature? Well, I disagree, but ok, go for it. Find occasions in which some detailed planning and design is necessary? Hey, do it - just don't lose it and end up in in(s)anity land again.

What's my point? Well, it's that the real problem with programming is that developers aren't competent enough. There is not enough understanding of core programming ideas - either that or there isn't enough self-discipline to appy them: Reduce duplication; encapsulate; reduce coupling; increase cohesion; emphasize clarity; resist the urge to obfuscate; no matter how tempting it might be, choose the plain way to do something rather than the really fancy: Avoid the way that uses some new fangled language feature unless you can demonstrate the plain way is going to be a serious problem.Whatever you do, avoid falling in love with object-oriented design for its own sake (or functional programming for its own sake). You should be able to show how everything you do emphasize clarity and reduces duplication and coupling. At the end of the day, a good program written in Python should look almost identical to the same thing written in Java. What are your objects? What are their functions? How have you removed duplication? It's not a sexy problem. Switching to a new programming language or a new methodology won't help. It's just the slow grind of educating people, educating ourselves, and keeping things as simple as possible.

Think about it.

Sunday, March 09, 2008

Hitting the Reset Button

All too often in the software world we convince ourselves to keep going with a design that just wasn't quite right from the start. We're not willing to say, let's scrap this and use what we learned to make it better next time. The result is that the technology becomes increasingly crufty and after a while, it's hard to know where to even start to improve things. I think it's important to have the courage to make tough decisions and rework designs that need it as soon as possible, even if it means rolling up our sleeves to do some hard work and dealing with some short term pain during the transition. I've quoted a piece of an interview that CNN did with Steve Jobs below, but I'd like to first show the key highlight, at least from my point of view:
But there always seems to come a moment where it's just not working, and it's so easy to fool yourself - to convince yourself that it is when you know in your heart that it isn't

It really is so easy to fool yourself. I think it's true that the great companies and great teams don't just come out of the gate with winners; rather they have the humility and courage to evaluate their work and start again when they have to. Anyway, here' s the rest of the part of the interview I wanted to quote:
At Pixar when we were making Toy Story, there came a time when we were forced to admit that the story wasn't great. It just wasn't great. We stopped production for five months.... We paid them all to twiddle their thumbs while the team perfected the story into what became Toy Story. And if they hadn't had the courage to stop, there would have never been a Toy Story the way it is, and there probably would have never been a Pixar.

We called that the 'story crisis,' and we never expected to have another one. But you know what? There's been one on every film. We don't stop production for five months. We've gotten a little smarter about it. But there always seems to come a moment where it's just not working, and it's so easy to fool yourself - to convince yourself that it is when you know in your heart that it isn't.

Well, you know what? It's been that way with [almost] every major project at Apple, too.... Take the iPhone. We had a different enclosure design for this iPhone until way too close to the introduction to ever change it. And I came in one Monday morning, I said, 'I just don't love this. I can't convince myself to fall in love with this. And this is the most important product we've ever done.'

And we pushed the reset button. We went through all of the zillions of models we'd made and ideas we'd had. And we ended up creating what you see here as the iPhone, which is dramatically better. It was hell because we had to go to the team and say, 'All this work you've [done] for the last year, we're going to have to throw it away and start over, and we're going to have to work twice as hard now because we don't have enough time.' And you know what everybody said? 'Sign us up.'

That happens more than you think, because this is not just engineering and science. There is art, too. Sometimes when you're in the middle of one of these crises, you're not sure you're going to make it to the other end. But we've always made it, and so we have a certain degree of confidence, although sometimes you wonder. I think the key thing is that we're not all terrified at the same time. I mean, we do put our heart and soul into these things.