Bacon Flu

The United States Government, paragon of doing REALLY IMPORTANT THINGS, has declared that the swine flu henceforth be referred to as H1N1, so as not to offend the pork producers of the world.

In retaliation, I am now calling it the bacon flu for the foreseeable future. At least until it mutates into the ham sandwich flu.

DesignAday – Truism

“Broken gets fixed, shoddy lasts forever.”

If you’ve ever worked in software on a mature (or even not so mature) product, you know this to be true.

(Via DesignAday – Truism)

Year of the 0xdeadbeef

I swear the first time I saw the phrase “Year of the Ox” today I thought, “wow a whole year celebrating software engineers!” Then I realized I was a moron.

If you don’t get it then you probably aren’t a software engineer. Good for you!

DaVinci

If you have the time and you are local to San Jose, I highly recommend the Leonardo Da Vinci exhibit at the Tech museum. It’s a fantastic walkthrough of many of his mechanical works, complete with almost full-size mockups, all of them beautifully crafted.

The Tech museum focuses on the engineering side of things, but about a quarter of it is devoted to art and general science as well.

The exhibit is huge, and takes about an hour just to walk through and see everything, let alone take it in. You get a great sense of the state of the art of scientific and engineering thought in the 15th century, and it’s really amazing how close he came to the kinds of physical discoveries that Newton is known for. If only the mathematics had been there…

I believe it closes on Jan 25, so you have one more weekend to check it out!

Comedy gold

I present to you, the anti-CuteOverload:

Fuck You, Penguin

(Via a little birdie.)

It’s not just me.

I can say this much better myself, so I’ll let the article do it. I’ll just add that I’m hopeful that people are starting to notice that we’re paying the price for short-term gotta-have-it-now-or-we-die mentality.

More Than Coding Mistakes At Fault In Bad Software – Wolfe’s Den Blog – InformationWeek

(Via slashdot.)

Always a good sign…

When your CEO departs after the startup has existed for only 9 months or so. sigh. Oh well, it was a decent technical progress day. If you can call contemplating a mashup of LabView, C dll’s, .net code, a lolcat and a Rick Astley video progress with a straight face. Come to think of it, that would be pretty cool……

Windows 7

s/Vista/7

Why software is hard (or Software Engineering for Normal People)

“We’re falling way behind Jack!”
“We’re not making cheese sandwiches!”

“Dr. Grumblyplonk”, I hear you say, “aren’t you just implying that you think you are smarter/better/cuter than people who don’t work in software? Aren’t you trying to justify your high salary/prima donna attitude/Henry Miller Aeron Chair by overstating the complexity of your work?” Yes, of course. And by that I mean NO.

Here is what I mean by this: *good* software is difficult. Ridiculously so. It doesn’t take a smarter person or a certain kind of smart person to do software well, it takes time and care. By difficult I mean resource intensive but that does not necessarily imply manpower. More manpower sometimes can help, depending on the project, but there is a critical value for the size of a team vs. the complexity of a project. Beyond that you get diminishing returns; below that you get burnout. I believe the reason for this has to do with the quantity of a software system that needs to be fully understood by each team member for mistakes in integration to be avoided. The closer an engineer has to full understanding, the more likely they will anticipate problems before they appear. Fragment a team too much, and miscommunication in the real-world and in the software lead to bugs. Focus the team too much on one person, and well, accidents do happen.

So what is good software. Good software is flexible, extensible, reusable, and robust. There’s an acronym in there somewhere. Fail to make flexible and extensible software, and you will (often) be back to the drawing board, at a minimum rewriting whole swaths of code to adapt to new requirements. Fail to make software reusable, and you will be reinventing the wheel each time a new project comes along. Make software that’s not robust and you will spend money continually on product support, lose money to customer dissatisfaction and generally look like an idiot. Meanwhile, your competitor, who may not have better technology or vision or engineering talent but DID take care when building their product, is cashing checks that should be going to you.

Since this is becoming long, I’ll take each piece of FERE and post separately about those.

Startups: founders

Startups have founders. They are usually smart, charismatic, convincing, and most importantly, rich. They have an idea, usually broad, a vision, usually wildly optimistic, and they have the wherewithal to build a company and take huge risks. They are however, not perfect people. Most of the founders I’ve had the pleasure to serve are one issue people: they know a narrow area and they know it well. It’s served them well in the past, therefore that narrow experience applies to all areas and disciplines. This can spell disaster, especially if the founder is also funding the company.

In this case, the founder is going to be seeing his money rapidly dwindle, while to his eyes a bunch of people doing things he may not fully understand appear to make no progress. Now it’s entirely possible that they AREN’T making progress. However, proper software engineering, obvious progress is often very slow at the beginning (design, architecture), then rapid at the end when implementation gets going. If your founder knows nothing about software engineering, he might fall back on his experiences with other disciplines, say mechanical engineering, and expect the same type and rate of visible results.

Now we have the makings of a disaster: a worried founder and an engineering team that is trying to do it’s job in the best way it knows how. This team is also trying desperately to please the guy with the greenbacks. So they will be accommodating: change plans, change designs, short circuit good engineering practices, make some kind of result any way possible. All of these things make the founder and possible the company happy in the short term, but may destroy it in the long term. Avoiding good engineering at the outset, and the investment in time and thought that requires, will ultimately lead to poor quality, inflexible designs, and most likely vast rework in the long term. If those retraced steps coincide with other stormy weather for a company, it make mean the end.