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.
“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
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. ;)
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!
I confess Im a recovering engineer. And Guy Kawasakis latest top ten list brought a smile to my face: The Top Ten Lies of Engineers
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.
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!!
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.
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.
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.
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.
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.”
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.
As a software engineer I have to say you missed the biggest lie of all:
(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.”
It took me a long time to realize that software engineering and mechanical engineering had a lot in common. I spent many years in the automotive business where I learned the secret to design: prototype, prototype, prototype. I even developed the equivelant of extreme programming for car design. I once built a working prototype of a full size wagon in four and a half weeks. The goal is to prove the concept before you spend a penny on the details.
Engineers and project managers in the mechanical world are married to GANTT charts. In the software world they are married to release cycles. They eliminate whole prototype iterations in order to meet deadlines. Thus forcing customers to test prototypes.
Great list Guy.
If a VC doesn’t do a “technical due diligence” on a company they are thinking of investing in, that VC is incompetent.
Questions about scheduling, bug tracking, scalability, software architecture, etc would be a standard part of such a technical due diligence investigation. This investigation would be done by an experienced software engineer – someone who can see past bland assurances and ask about the details. This person acts as an intermediary between the VC (who typically lacks technical knowledge) and the engineers at the company.
As a marketer who has heard every one of these and more, I thank you.
For those who don’t “get” marketing’s value, I like to explain is like this:
Marketing is the only thing standing between your company’s strategy and a tactical reality of shoddy product delivered late to a market that doesn’t want it, need it or understand it.
Let’s look at the marketing side, then:
1) “We need to beta test now! Our advertising schedule demands it.”
We haven’t bothered to keep up with the project, but we’d really like running those flashy ads we came up with.
2) “We don’t need to know about engineering”
The engineers will f&*ck this up anyways, but our superior marketing skills will sell it.
3) “You guys should use agile development! And best-of-breed tools”
We’ve got no idea what that is, but it could be turned into an article in a popular magazine.
4) “We need an extremely scaleable architecture!”
We don’t know how many customers we’ll get. In all likelihood, a single server will be able to handle them, but Google is scaleable too! Plus, it’s a great bullet point
5) “We’re Web 2.0 standards compliant!”
We’ve got no idea what those standards would be if they bit us, but it makes a *really* great bullet point.
6) “Our entire product line is cross-platform”
We’ve seen a prototype on the PC. But really, those engineers are nincompoops anyways – my son writes RealBasic, and that runs on Mac and PC, so how hard could a port be?
7) “We leveraged our excellent Quality Metrics Program to assure 100% bug free software.”
It didn’t crash for 2 days. Ship it!
8) “It has been developed using an international team across three continents and is leaping past the competition due to this cross-cultural experience!”
American Management. Russian Design. Indian coders. A complete in-house rewrite because it really wasn’t what we expected.
9) “Our focus groups loved it!”
We really have no opinion whatsoever on this, but by asking cleverly worded questions, we got one out of three people to reluctantly agree that he might install this on his machine. If it was free.
10) “Our marketing campaign is spot-on!”
We’re insulting the majority of our customers, but boy, those dinosaurs are funny!
Ah yes, life on the engineering side is not a walk in the park, either… ;)
For those who don’t “get” marketing’s value, I like to explain is like this:
Marketing is the only thing standing between your company’s strategy and a tactical reality of shoddy product delivered late to a market that doesn’t want it, need it or understand it.
I’ve been in various high-tech marketing roles for more than a decade. I gotta take issue with this statement.
If a product is truly crappy (i.e. no one wants it) – no amount of genius marketing can sell it. It is hard enough to sell a good product.
What is needed to bring great products to market is better collaboration between engineering and marketing – so that the company only builds products that the target market wants in the first place.
Great Post Guy…
A favorite story is one from my data which we talked about on my blog just this week.
In it he asked an engineer when the piece of code he was working on would be done. He got the soon. Week after week it was the same with no sense of anything ever going to finish.
Finally he changed the question and asked, when will it meet the spec, to which he got the response “That was 4 weeks ago”.
Or something along that line.
Over 1000 defects?
Guy Kawasaki has a funny and true to life list of the top ten lies engineers tell. But, almost as an asside he says:
Generally speaking, if the largest number of documented bugs doesnt ever exceed 1,000, it means that the company isnt t…
We run a venture-philanthropy program for young social entrepreneurs in developing countries.
It would be interesting to hear your “10 lessons for young entrepreneurs”.
Lies of Engineers
Guy Kawasaki posts another brilliant top-10 list. #9 really resonates:
Our beta sites loved the software. In twenty five years of working in technology, Ive never heard a company report that its beta sites didnt like its s…
Lol. You have a gift for writing and telling the truth. I laughed a lot. I can’t wait to start your book this weekend…! Looking forward to it.
The Top Ten Lies of Engineers
Guy Kawasaki latest top ten list is for engineers. Ouch!
Top Ten Lies of Marketing
In response to Guy Kawasaki’s Top Ten Lies of Engineering:1. quot;Of course we need that feature.quot; :: We have no friggin’ clue what that feature does, but our competition has it in their product, so we need it to!2. quot;Good work on…
“This should just work.”
Is the top 10 (or should that be top 100? ;) lies of Marketeers coming?
I wonder what Scott Adam’s Dilbert (who is still an engineer at heart) will say to this list. I think he will miss his “lies”:
1. All the features described in the proposal have beeen implemented. (The user is a complete moron. She did not tell me about her needing this, that, whatever while I was doing the specs and now she is asking for it.)
2. The GUI for my product is very beautiful and intuitive. Even my Mom can navigate the screens.
3. The documentation is self explanatory. All the features are covered in it in case you need to refer to it.
What about the top ten lies of CEOs? Internal and external? Actually the internal are more interesting.
The Top Ten Lies of Engineers
Le bugie degli ingegneri
GuyKawasaki ha scritto la sua personale top ten delle bugie degli ingegneri …
Business, lies and silos
Some like Seth Godin readily acknowledge that marketers are liars. I agree with him and extend the proposition to all business people, myself included of course, especially if one considers that it is a lie to omit something. On the
I eat badger poo!
As a SQA Engineer for about 11 years, working closely with programmers, I believe the biggest lie they tell is: “I’m done”. The gap between what they think that means and what it means to me is staggering. I advocate for the end-user, and to me it means: “ready for end-user”. Like most deception it is not really a lie, just a different point of view. An ordinary person assumes that something works, a SQA Engr assumes things don’t work (and is in the business of demonstrating why they don’t scientifically.) We work in the realm of what can be proven repeatedly, not what can be imagined or hoped for.
I am an engineer, so I was getting worried there when I saw that picture of the engineer. However, most of the stuff you mentioned is very true. It took me about 3 months in my first permanent job just out of University to say to a Marketer “yes, I now understand that we need you (Marketing)”. He then tried to get me to walk around the office and repeat that to everyone. Needless to say, I got quiet and went back to my desk, but I have gained an appreciation for taking even technology driven innovations through the process of making them as useful as possible to customers. So this blog didn’t offend, it mostly confirmed what I have been learning.
BTW, congrats on reaching the top 50 on Technorati! Keep up the great blogging!
Another common one:
“That feature is easy to build. All we have to do is…”
It’s always way easier on a cocktail napkin than in implementation.
Now that I think about it, this applies to engineering, marketing, sales…
When you assume…
Having spent the past 8 years developing dynamic online applications for customers all over the place and running a few businesses who rely on “software engineers” to get stuff done, here are my words of wisdom ;-)
1) triple your timelines and double your budget RIGHT OFF THE BAT!
2) start ugly and work your way to “pretty”
3) establish meaningful milestones each step of the way, be sure to share them with both engineers and execs
4) nothing ever goes as planned and keep multiple sequential backups all over the place
5) higher the quality of the work the longer it takes to get done BUT the less problems you have during testing/launch
In defence of software engineers, their jobs are highly undervalued by execs and considering the complexity of their tasks under deadlines, they are among the smartest people I know.
Founder of http://myfoodcount.com – Free & Anonymous Health Monitoring
insulting and mostly bogus. Most projects are screwed up by marketing changing their mind, not being able to let go of the “entire vision” long enough to ship a “good enough” product (with the 20% of the features the product actually needs) that is well built; not being able to be realistic about how long it takes to write software, etc. Most (but not all) code ends up being bad because marketing can’t seem to act like anything other than spoiled kids who want their cake and eat it too – this results in engineers having to RUSH all the time and who can do great art when rushed? And software is art plain and simple.
Read “Get Real” by 37signals.com
ROTFL (and crying, as well).
You certainly got it right with this top ten! Being an engineer myself, I have to admit that all true (though mostly because of narrow-mindedness, not plain incompetence :-)
Now, how about a ‘Top 10 lies of the marketing department’ for the sake of err… balance?
And another for CTOs (their an entirely different breed).
I do hope all engineers read this!
#8 (Outsource to India). This isn’t a CTO-driven myth; it’s an investor-driven myth. Most CTOs who are technology-focused probably don’t care about cheaper, and they certainly believe that the engineers’ proximity to them is what is going to make the product faster and better. The CTOs who are business-focused either lack personal experience or are influenced by external factors (read investors, press, etc.), and thus make false assertions about outsourcing. Though the business wisdom of the day, promulgated by the press to investors and people who sit on company boards, has been that outsourcing is the hammer that will solve all development problems for emerging, leading edge, or any other complex technology, it rarely, if ever, works as advertised. Outsourcing is an executive management lie, not an ‘engineering’ one.
I have never told any one of these lies.
11. The design specifications are complete, and up-to-date.
When I was a tech writer, this was a deal-killer. It was heartbreaking to find out you’d been documenting code (and even features) that had been tossed out two months earlier.
For some engineers, specifications must feel like clingy relationships – they tie you down, don’t let you sleep at night, and take away your freedom.
Hopelessly cliche-ridden (gawd, the picture!) and software-biased (writing about what you know, I guess…).
Both engineers and managers need to avoid reinforcing their respective cliches.
I like Glenn Kelmann’s points much better :-)
Kawasaki recently posted “The Top Ten Lies of Engineers”. It was humorous but definitely struck a chord with my situation. Specifically #8…
Amazing! Both true and false at the same time! It boggles my engineer’s mind!
No, honestly. We’ve all said things like that. The best thing I can add to that is “It should take N days to complete”.
On the other hand, noone but engineers seem to understand that
– Software should be released when it works, not when the management sets a release date.
– When software is feature-complete it should go into a thorough testing phase before releasing it.
– Adding developers to a late project will make it later.
– Adding features to a late project… oh my god, just because you moved the release date back, did you really think there’s enough time to add MORE?
– No feature is ever “small”. It takes a lot of work.
– For software to fulfill it’s requirements, the requirements have to be clearly stated. Without that, there’s no way you can test whether the software fulfills it’s requirements.
– No, trying out a few things isn’t testing. Testing means automated, repeatable tests with trackable results.
Now most engineers I’ve met don’t act like they realize this either. But then, most of them don’t stand up to management and tell them that their opinions.
Good fun reading. I admit to telling these lies at some point in my career. However many of them where much earlier in the day. Having 15 years under my belt, I am not so delusional anymore.
PS, I can back up my Mac/Windows porting architecture: It uses a common code base and has stable implementations on both platforms!
Good analysis Guy.
This list shows the symptoms of a greater issue in the IT world of today… communication. Unfortunately, lack of proper communication points to the CEO and his management staff.
Guarding territory, protecting subordinates, and hidden agendas take away from what a company should be.
These issues have been the around for all of my 27 years in programming and management. They have just changed form every few years. Bring the marketer, engineer and stakeholders together for the common goal – money!
Management has to remove the mud slinging and get everyone focused on the goals. You are definitely right when the engineer says “I don’t know anything thing about marketing” and he acts accordingly. Just imagine how powerful your employees would be if they fully understand why they are supposed to perform some task. Employee buy in to a task is just as important as being on fire about your product.
Managers you all now have new tasks… tear down the walls, get everyone on the same page, and go make some money.
The Real Top Ten Lies of Engineers
Guy Kawasaki, a Venture Capitalist with technology roots (Apple), writes the top ten lies of engineers. He is sooooo wrong! His list doesn’t come even close with the worst lies of engineers. It looks like he never talked directly to
Here is what I think the Real top ten list is:
(Sorry for “co-opting” your blog, Guy, but I wanted to reply to this guy’s comment.)
To “Bob” – I’ve seen these lies played out by engineers in the past. It’s too easy to blame all the problems on marketing (I’ve done it many times in the past – and it’s fun, too!). Perhaps the engineering team should push back a little when marketing comes to them with yet another poor product? If they don’t, they’re just as guilty as the marketing folks.
I’m an engineer with too much experience to suffer with the “this and them” experience we have between marketing and engineering. If these two groups cannot work together then it’s not a real company, it’s bozo-land, and you should either go to another company where they do work together or start your own company and make it right.
(And, yes, I have read the 37Signals “Getting Real” book. I find it a real good variant of the “Agile” development methodologies. The 37Signals folks are very sharp, and their products are really good. They are in balance.)
Reminds me of when I did some coding in the good old days.
Mike Johnston’s comment about it being frustrating that an employee’s obsession with standads-compliant software, because it invariably didn’t work with IE, is just flat-out wrong-headed.
Why not have a goal to create web pages that work for all users on the Internet? And not just IE users (IE 6+ mind you!)
You think Microsoft wouldn’t make IE standards-compliant if we refused to let their proprietary junk muck up the system?
Remember the phrase: “Windows isn’t done until Lotus won’t run?”
Turnabout is fair play.
The Top Ten Lies of Engineers
Guy Kawasaki on the top ten lies of engineers:
After a several month hiatus, I would like to return to my top-ten lies series. So far, Ive covered entrepreneurs and VCs, Todays topic is the top ten lies of engineers.
The biggest lie of all:
Software is written by programmers. Hardware is designed by engineers.
Gene Kranz, director of NASA Mission Control through the Apollo program (making him arguably the geek di tutti geeks) had a great saying in this vein (from memory):
“Engineers will wildly overestimate what they can do in one year and wildly underestimate what can be accomplished in ten.”
links for 2006-04-29
Signum sine tinnitu–by Guy Kawasaki: The Top Ten Lies of Engineers more great lies from Guy (tags: business programming software) Pushing String SAML expert at sun (tags: sun blog xml saml unread)
I may be wrong headed but check your stats. IE still owns 85% of the market. Are you seriously saying forget about it? If you are building an app to work with “the internet” as you call it… then it better work on IE. Period.
I am a Mac user myself so I feel ya- but those thoughts don’t pay the bills.
have you been speaking with out tech guys again? :-)
Kowasaki on Lies from Engineers
Guy Kowasaki recently posted the Top Ten Lies Told by Engineers.(as an engineer, Im a little insulted by the photo he chose to display
Kawasaki on Lies from Engineers
Guy Kawasaki recently posted the Top Ten Lies Told by Engineers.(as an engineer, I’m a little insulted by the photo he chose to display…well, not really). As I’ve said before, what Guy has to say is always insightful and worth
“The feature works but you can’t touch it because it’s in development and if you want to see it, I’ll give you a demo on my devlopment machine”
I agree #4 is silly but I don’t buy your statement that scalability is not an issue upfront, and the implication that it is something that can be put in later. I don’t mean that a 0.9 release has to be tested with 100s of thousands of users, but if the underlying architecture – think algorithms and data structures – aren’t built to scale, you have a complete rewrite on your hands. As I’ve argued on my blog, this “scale later” argument perpetrated in books like 37Signals’ “Getting Real” is dangerous advice.
Half a Dozen Top Announcements
There were a number of announcements that warrant mentioning. The president’s popularity is inversely proportional to the price of gas. And here I thought spending $34.00 at the pump was patriotic. Guy Kawasaki has an excellent post on “The Top Ten L…
Items of Interest: 2006.04.28
Things that I found interesting on April 28. 2006:
A Blog Without Comments Is Not a Blog – Thoughts from Jeff Atwood. I think that sometimes the opposite becomes true (especially for some of the more popular sites with multiple contributors): A blog w…
I’ve seen hardware botched just as badly as any software. The difference is, it’s much harder to ship botched hardware.
links for 2006-04-30
Simply Ming: Recipe: Pepper-Crusted Tuna, Avocado and Cucumber just printed this recipe…must.make.soon. (tags: recipes) Simply Ming: Recipes : Cilantro Oil can’t forget this… Signum sine tinnitu–by Guy Kawasaki: The Top Ten Lies of Engineers (tag…
My personal favorite:
‘That isn’t possible…’
The moment a developer says that you know he just doesn’t want to do what you asked him to do and that he disagrees with you. If he likes the job he would mention the second most used lie by developers:
‘I can build anything you want with this language/platform/set-up…’
Las mentiras de los ingenieros
Me temo que hoy es el día en el que revelaremos el verdadero significado de muchas frases que dicen los ingenieros, sobre todo pensad en cuantos proyectos dependen de estas afirmaciones
1.Vamos a entrar en la fase de beta testing….
A trip back to the good old days.
Guy Kawasaki takes me back to my consulting days with this post (Top Ten Lies of Engineers)
3. Ill comment the code, so that the next person can understand what I did. This is a lie of good intentions. Really, the engine…
Microsoft Security Notification
top 10 lies of engineers
The Top Ten Lies of Engineers
by: Guy Kawasaki 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….
How many people really roll on the floor laughing?
Top Ten Lies of Engineers
Guy Kawasaki has a great new post on his blog entitled Top Ten Lies of Engineers. You know, this would be funny if it weren’t strangely true. Luckily, we have a great engineering team at nCircle – our product development…
There was a time when I actually valued your opinion, but now I’m not quite sure why. You’re obviously more a “marketeer” than an engineer. Pretty much every one of these items is either complete crap or forced upon engineers by unreasonable management requirements which make it not the engineer’s fault anyway. You’ve obviously spent too much time on the SIDE-line instead of the FRONT-line. Unless you’ve actually been there personally you’re just parroting the whining of management and marketing who start half the problems in the first place.
Wouldn’t it be great if the “higher ups” didn’t have to deal with us incompetent engineers and could just snap their fingers and instantly get whatever they asked for? Of course, best be careful what one asks for…
Tim: I suggest you read today’s post about marketers. You’ll be happy. I am not an engineer at all, incidentally. But I’ve had to listen to these lies for years.
Guy Kawasaki: Top Ten lies.
Guy Kawasaki has a post, actually two posts on the top ten lies of engineers and marketers. It’s a fun read, even though one or two of those ‘lies’ are going to look straight at you and take a shot:…
Guy Kawasakis The Top Ten Lies of Engineers
Guy Kawasaki is a well-known entrepreneur and writer in high-tech. He recently wrote about The Top Ten Lies of Engineers. I had to step back and think about how many of these applied to me or any of the teams I have been a part of. I …
Websites are always in beta
Your website is never finished. Web pages dont go to press like printed leaflets and brochures do. And that unfinshed quality is a great thing.
I started in work doing print design. The worst moments were always when advance copies…
I think this one should be able to bump out one of your top ten Guy:
“I write software therefore I know a lot about usability”.
Not lies but the response to bug reports that bug me the most and hear every day:
“It is no worse than before, but yeah, in general, it would be good to fix”
Or a variation:
“That bug has been there since it is implimented, it is not a new issue”
How about this one
“It’s not our bug, it’s the 3rd party software’s problem”
I hate to say it, but I HAVE seen code that was faster to throw away and write again than debug. It was also about 1/4 the length.
Top Ten Lists: Customers and Customer Service
This is a good cross post from Young Joowith his “top 10 list of how you as a software engineer…
Top Down Pointers – Professional Blogs
I am often asked about my own favorite blogs (in addition to Techcrunch and Mashable, of course). I am also often pinged about starting points – where to begin with mobile data, with web 2.0 and with internet software. I will do my best and share a mo…
I’ve heard these so many times now that I find myself actually remembering when I used them…. HA!
Better, Faster and Cheaper?
Somehow weve 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 be…
Lies, damn lies, and top 10 lists
It all started innocently enough: Guy Kawasaki posted the The Top Ten Lies of Venture Capitalists back in January, followed closely by his The Top Ten Lies of Entrepreneurs. Now hes back with the The Top Ten Lies of Engineers and The Top Ten Lie…
This entire list is why real (electrical) engineers regard software engineers with a great deal of suspicion.
And why mechanical (especially aeronautical) engineers regard electrical and software engineers with suspicion and envy.
And why civil engineers regard everyone as slipshod.
Funny stuff but… these lies are far too optimistic to have been spoken by any real engineer. I can only hear that kind of bull coming from an MBA/CTO/VP or some pumped up new grad who wants to be one. Do you have any idea how much trouble you can create for yourself by saying stuff like “our architecture is scalable”? That kind of statement (even if it’s true) will put a noose around your neck. Let’s leave lying to the marketing department, shall we?
I can’t really argue with this. I have a similiar list of “Lies Software Engineers Tell”. You can find it here. http://www.notesfromthecape.com/2006/06/the_ten_lies_so.html
Ive added a link to my links section, but one blog that Ive found very informative is Guy Kawasakis (http://blog.guykawasaki.com). He has written a few books, and has plenty of experience in the VC space. He posts very frequently, here a…
I’ve added a link to my links section, but one blog that I’ve found very informative is Guy Kawasaki’s (http://blog.guykawasaki.com). He has written a few books, and has plenty of experience in the VC space. He posts very frequently, here are a few of …
Guy Kawasaki Top 10 Conspiracy
Guy Kawasaki is planning on taking over the blogosphere. I have proof!!! Beyond the strange resemblance to Dr. Evil, there are all the suspicious things that Guy does: He writes lots of top ten lists. We all know that Top…
Here’s one that I employ most (shamefully)
“Try re-creating the bug again. If it doesn’t happen again, I think you missed something.”
“11. Writing code makes me an engineer”
Didn’t there used to be something called a “programmer”? I wonder what happened to those.
“This code is so bad it would be faster to write it all from scratch than debug and expand the current shipping code.”
– that happens quite often and quite ofter that is not a lie, actually.