The Top Ten Lies of Engineers

After a several month hiatus, I would like to return to my top-ten lies series. So far, I've covered entrepreneurs and VCs, Today's topic is the top ten lies of engineers.

1. “We're about to go into beta testing.” This is a meaningless statement because it doesn't matter when you go into beta testing--what matters is when you come out of beta testing. (The only hard and fast deadline for coming out of modern-day beta testing is “before you run out of money.”)

In the good old days, “alpha” used to mean “all features are implemented though not necessarily working properly.” “Beta” used to mean “there are no more repeatable bugs.” Nowadays beta means “we've gone as long as possible past the shipping date that we promised our investors.”

2. “I don't know anything thing about marketing...” This is a lie of false modesty. The engineer is thinking, in totality, “I don't know a thing about marketing, but how hard could it be compared to what I'm doing? I should run marketing and engineering. I just hope that the marketing the MBAs come up with is worthy of my code.” However, don't worry too much about this lie because it self-corrects as the engineer misses deadline after deadline and comes to realize that he has bigger issues.

3. “I'll comment the code, so that the next person can understand what I did.” This is a lie of good intentions. Really, the engineer did intend to comment the code but as the schedule slipped, priorities changed. The question put to management became: “Do you want me to comment the code or finish it sooner?” Guess what the answer was. Luckily, the lack of comments usually doesn't matter because the code is so crappy that a total rewrite is necessary in a year.

4. “Our architecture is scalable.” This is the lie that I enjoy hearing the most. Typically, an engineer who has never shipped a product says this after creating a prototype in Visual BASIC. The whole conversation goes like this: “Google's architecture isn't as scalable as mine. They can support 25 million simultaneous searches. We will be able to easily handle a billion.”

Luckily, in most cases, the adoption of the product is slower than the CEO's “conservative” forecast, so scalability never becomes an issue. Yeah, those clowns at Google, Yahoo, Oracle, Microsoft, Apple, and AOL don't know anything about scaling compared to the engineer...

5. “The code supports all the industry standards.” This is almost a truth but for a short omission: “This code supports all the industry standards that I agree with.” The engineer has made a personal decision to ignore standards she doesn't like--for example, those promulgated by Microsoft. It's no big deal--customers will never know...

6. “We can do a Macintosh version right after we finish the Windows version; in fact, much of the Windows code can be re-used because of how we architected it.” The truth is that version 1.0 of any software is an experiment. It can be a magnificent experiment, but it's an experiment nonetheless. Thus, Windows version 1.0 is held together by duct-tape. The Macintosh version is a copy of the duct-taped Windows version written by an engineer who just finished college and got his first Macintosh a month ago. How hard could it be to learn to program for a different platform? C++ is C++, right?

7. “We have an effective bug reporting database and system.” Of course, the assumption behind the design of the bug reporting database and system is that there are no bugs in the code, so there's not much to database and report. Generally speaking, if the largest number of documented bugs doesn't ever exceed 1,000, it means that the company isn't tracking bugs carefully.

8. “We can do this faster, cheaper, and better with an offshore programming team in India.” Rank and file engineers usually don't tell this lie; it's the CTO who does. Somehow we've got it in our heads that every programmer in India is good, fast, and cheap, and every programmer in the United States is lousy, slow, and expensive. My theory is that for version 1.0 of a product, the maximum allowable distance between the engineers and marketers is thirty feet.

9. “Our beta sites loved the software.” In twenty five years of working in technology, I've never heard a company report that its beta sites didn't like its software. There are three reasons for this: first, many beta sites are so honored to get pre-release software that they don't want say anything negative. Second, most beta sites haven't used the software very much. Third, most beta sites don't want to seem cruel by criticizing a company's new product. Doing so is as socially unacceptable as telling someone that his baby is ugly.

10. “This time we got it right.” The scary thing about this lie is that the engineer really believes it. Again. The problem is that “this time” occurs over and over again. I have great faith in engineers and believe that in the long run, they do get it right. It's just that in the long run, we're all dead.

Addendumbs (sic):

“This code is so bad it would be faster to write it all from scratch than debug and expand the current shipping code.” (Joel.)

"I like thinking about architecture, but I can code." (Glenn Kelman)

"It works on my machine." (Gaurav)

"Of course I can let go of the code and run the business instead." (Jason)

"Even my mom can navigate the screens." (Nitin)

Powered by Qumana

Comments

[Tom Frauenhofer]

As a software engineer I have to say you missed the biggest lie of all:

"It runs."

(Variant: "It works.")

What this means is "I got it to do something once that I thought looked correct on the computer I wrote the software with using my test data." It does not mean "You can run it." Nor does it mean "It will run on arbitrary customer data."

[Smittie]

Internationalizaton and localization.

Bug filed: Strings are hardcoded, coder rolled his own character handling.

Bug closed: Product is US only.

You can pay now or you can pay later.

In this day and age, I18N and L10N questions should be a standard part of the technical interview. Not understanding I18N and L10N as sign of a coder who has not played in the major leagues.

Aloha

[John C. Welch]

I'd say a beta site that doesn't generate a ton of work for a product and flog it mercilessly is useless. I've been on both sides, and the worst thing you can have is a site that won't report problems, and loves everything.

I love Missing Sync, but I was merciless on the first betas of 2.0, because it was broke, and badly. It's now a great product, and the alphas of 2.5 are more usable than the initial 2.0 commercial release was, because the testers are hard as hell on the engineers.

What I always want to hear is, "The beta sites beat us like a baby seal, but they're happy with it now."

[Smittie]

So now we know what the marketing types think of engineers. Who are we going to get to write the engineering view of marketing.

You know, that part where engineering says that feature set will take nine months to implement correctly and marketing says, "great, glad we agree on 3 months."

Stuff like that.

Aloha

[Service Untitled - Doug Hanna]

The bug tracking thing is a good point. Most support departments are afraid of mentionings bugs to the engineering department because they get attacked. :P An effective system is needed by every tech company.

[Glenn Kelman]

Add to the list:
1. "Code-complete is delayed, but we'll still make the ship date." Delays cause delays.

2. "We need __[Java]__ coders" Hiring for skill-sets rather than talent results in overpaying for mediocrity.

3. "I like thinking about architecture, but I can code." Start-ups need coders.

4. "It's coded to be internationalized, we just haven't internationalized it yet." See Guy's Mac comments.

5. "We'll put another resource on it." People aren't interchangeable resources. Code ownership is crucial to pride & productivity.

6. "It's just QA." Hardest position to hire for, crucial to your reputation.

7. "He doesn't have a CS degree." Some of the best engineers studied physics.

8. "We don't have time for customer feedback during beta." Pay now or pay later.

9. "It's a quick skunkworks project..." That will be half-baked, poorly integrated with the main product & cause resentment.

10. "Beta" Froogle has been beta for years. Stand by your work: ship it.

11. "If he doesn't work out we'll fire him." Hiring quality is especially crucial in engineering. Bozos replicate.

That said, engineers are the life-blood of a technology company, and most often are the truth-tellers too.

[bjs o^o]

This stereotype of an engineer is indeed common, one of the reasons I never consider myself an engineer but rather a software architect or developer. Engineer sounds too much like Dilbert.

[Clark Jones]

I laughed so much reading the list i almost fell of my chair, I've already forwarded a link to my boss so he can realise it's not only me!!

[Jon Husband]

Glad that you've used Qumana more than once .. and I read your comments on Tris' blog regarding "there must be a better way" ;-)

Yup .. we are striving for continuous improvement, and to be best in class, and rely on challenging feedback and constructive criticism from users. There are a few areas of improvement that are constrained by the core editor underlying the app, but the license we purchased entitles us to all improvements when implemented.

In addition, we are working on a few minor bugs, and a set of improvements suggested by users over the last 6 weeks. the next release should be better .. and as always, we appreciate challenging feedback.

Won't pester you any further .. and as you may have noticed, you can disable the "PbQ" tag if it annoys you.

[Mike Johnston]

Laughing so hard about the standards issue. I had a young coder who worked for me that would spend hours on end making sure that his code was 100% extensible and W3c compliant to the most granular detail.

Every single time, without fail, it simply did not display or work correctly in IE. And of course every single time, without fail, the response was the same from the coder, "But it's 100% standards compliant. Works great in FireFox."

And that was it; he washed his hands of any issue. He could never understand while I was completely frustrated with him constantly.

Good stuff Guy!

[Jason]

Guy -

As an engineer and someone who is trying to get an early stage startup running, I thought I would add one more:

"Of course I can let go of the the code and run the business instead".

I actually just wrote an entry about this very topic. Engineers typically want nothing more than to code. They feel the problem they are solving is all code related and the business aspects (marketing, partnering, contracts and other things) will take care of themselves with a great product.

Us silly engineers. ;)

jason