I agree, keep it simple

This Sunday afternoon, after eating a delicious Fiorentina's steak with some friends in a nice cool location near Bologna, I went home to have some rest (!) .

I opened my laptop and start wandering the web... I found an interesting blog post by Cregg Hardwick, dated 2006, hosted by techtarget.com .

There's no direct link to the specific post ("The Golden Rule: keep it simple"), but here's the link to the page: link (I also pasted his post text here...)

The golden rule: Keep it simple
18 SEP 2006 06:12 EDT (10:12, GMT)
Remember Pascal? When I was in school, we studied Pascal, but everyone "knew" that C was where the action was. Pascal was far easier to learn and to read. Its strong typing protected us from all manner of evil, and it was powerful enough to express any concept that came up in a college CS curriculum. But of course, the operating systems of the day were written in C, so C was what the young turks like myself all aspired to. Then I went to work in the real world.

At SoftDisk Publishing, we programmed in everything. We took software submissions and licensed shareware and everything had to be cleaned up, normalized and/or stabilized. All of the in-house development was done in Pascal, C++, or an early database language called Clipper (which was really just an early compiled dialect of BASIC with data access constructs like Microsoft's "new" LINQS). I worked in all of these languages, but I haughtily thought of myself as a "real" programmer. So when I was given my first major project to run, it had to be C++.

Three horrible months of high blood pressure, lost sleep, and nightmares later, I had learned a valuable lesson. Every mistake and omission that Pascal prevented, C++ invited. The syntax, which aficionados referred to as "mathematical," was obscure, case was important, types could not be trusted, buffers could overflow, memory management had to be attended to, pointers could point to anything and crashes were simply a way of life.

For the "gamer guys" down the hall, C++ offered an easy way to write directly to the hardware, and was far superior to writing directly in assembly language. They were able to get the most out of the language by applying standards, working insanely long hours, and dedicating a team to each project. But in my group, each developer was responsible for one new development project every other month, plus a host of monthly editorial duties, including work in other programming languages. For our group, Pascal was a vastly superior tool.

I am reminded of this fateful lesson each and every day at work. Yes, friends, I am engaged in the treasonous practice of creating a simple little ASP.Net application. We have at our disposal the full suite of Microsoft tools, from the impressive IDE to their shiny new "Guidance Packages." The latter are really kind of neat. Imagine a cross between a Lotus Notes template and a hands-on tutorial, and like everything Microsoft makes, it's extensible. And it's a darn good thing too, because as nice as all these tools are, and as impressive the intellectual firepower that clearly stands behind them, they are mind-bogglingly complex.

Microsoft has spent billions solving problems that we Notes programmers had licked ten years ago. Sure, their solutions are better (in theory) in many ways, and granted, some of the Lotus solutions still have nagging weaknesses that haven't been improved in years (can anyone explain why it took until R7 for record locking, and there are still no good tools for automating replication conflict resolution?). But sometimes "better" means different things to different people.

Imagine if you went off to school to become an aerospace engineer and they told you that, in order to build rockets, you first had to understand quantum mechanics. After all, the old Newtonian mechanics don't work for objects traveling close to the speed of light, and most of it hasn't been improved in over a century. If you are like me, you might be sorely tempted to pull back your tuition check and inquire, "so what?"

History is filled with examples of this kind of reasoning error, and we have all seen their effect in business. Mainframes were bigger and more reliable than microcomputers for a long time, but that didn't stop microcomputer technology from dominating the industry. Microsoft's vast suite of development tools is impressive in its breadth and intellectual foundations, but is that what really matters? I mentioned the Guidance packages earlier. These "assist" the developer in building a complex multi-tier application, which has all kinds of theoretical benefits. My guess is that, after it matures and I get enough experience, I'll be able to do in a week what I can now do in a month. But I could get the same results in Lotus Notes in two days.

After the Space Shuttle Challenger exploded, one of the people who made up the Rogers commission investigating the accident was Nobel laureate physicist Richard Feynman. He's the fellow that many people remember for bringing a piece of rubber o-ring material and a glass of ice water out before the cameras to demonstrate easily and clearly how the material failed at low temperatures. What many people do not know is that Feynman conducted his own personal investigation of the entire space program, by the expedient of leaving all the reports behind and walking around talking to people. One of the areas he investigated was the computer system on the shuttle. He found that, over all, it was probably the best designed part of the shuttle system. What made it so good? It was simple. The shuttle designers deliberately under-designed the computer and built it using ancient transistor technology with tape cartridge to load its simple programs. It doesn't do much. But it gets the shuttle up and back down... every single time.

When it comes to choosing technologies, we should all keep this example in mind. The goal is not to have the best looking, or the most interesting, or the most "Enterprise class" or the most "scalable." The goal, is to solve whatever the problem is as simply and cheaply as possible. Anything else is a waste of resources, or an investment in artistic expression.
Posted by Cregg Hardwick

1 comment:

Anonymous said...

More or less, there is the KISS rule.
S-imple and