Image via Wikipedia
There is a science and art to great software development. The field draws committed individuals. Some are uniquely talented and capable while other much less so. Software developers are typically intense people that care a great deal about their craft. That intensity can sometimes be displayed in over statement.
With a nod to those I've heard these from over the better part of 30 years, here are a few of my favorite lies or "over statements" that they tell.....
1. I could do that in a weekend
The quick development time line assessment for a new feature, functionality or capability. And that is a weekend that has never happened for me. I have asked for it many times but the desired functionality has never, ever arrived on Monday morning. Or by the following Friday. I am not sure why the accomplishments of their peers are so undervalued by other developers.
2. It's completely modular
In the design phase, it's probably true. At the beginning, it is all Lego block interchangeability. After the second, tenth or hundredth line of code it is no longer true. And never will be true later. Nothing is as interchangeable as promised. Everything is as modular as a cord of wood. A cord of wood is kinda of modular, especially if you put enough effort into making the pieces fit together.
3. With the product debugged, we need to go back into the code and speed it up
Meaning it is time to install new bugs as we attempt to correct poor coding that while functional was slow. Good news is that it will be much faster. Bad news is that it will no longer be reliable. You, as the manager, have to decide whether you prefer reliable or fast. Both isn't on the menu.
4. I was here working until 4am
Which is true if you include "off and on" 10 minute coding periods , online game playing and pornography viewing in your definition of working. The truth is that the food, chair, bandwidth and sodas are better here than at the developer's home and after he was three hours into a game session and it was 11pm, he figured he would hang out and get credit for working late. Plus, the working late session provides air cover for righteous indignation and cranky misbehavior. And righteous indignation and crankiness are comfortable.
5. We need to tweak the UI (User Interface)
Image by Getty Images via @daylife
Meaning it looks worse than we think we can get away with and none of us really had the skills to deliver anything better prior to this. It is bad and will stay bad until it is taken away from the original developers. If they could have done a slick UI, it would already be there instead of the awful one in front of you.
6. Trust me, it will work for the demo
Just not for very long. Or at least, not for the entire demo. Hope as a strategy as it will be tested prior to the demo.
7. It is the server or bandwidth
"You see, if you weren't such a cheapskate," it implies that "my vision and superior performance would be realized and obvious. Now, my true genius is obscured by your cheap skate sensitivities. Away from me!!" You are the source of the problems with the code, not the author(s).
8. His or Their code is crap
This is said by developers of all other developers. There's is likely some truth to it. Then again, it is just different than the developer delivering the opinion would do it. And that makes it crap.
I must say I admire the creative act of software development and the skills of those capable of great work. Along the way, however, I have run into more than a few mis-leading statements about it from modest and great developers alike.
Had a good chuckle reading this...thanks for sharing this point of view. While I've seen all of these at various times, several of them are reactions to expectation setting gone astray. Developers who have worked in sweatshops will often take years to overcome CYA tactics, even after working in a healthy environment. Here are common management triggers for these behaviors:
1) Is it really going to take that long? Or, back when I was a developer... Or, when we first wrote it, it didn't take that long. (...before any customers or legacy code existed)
2) Can't we design it to take into account all possible business outcomes and be delivered next week?
3) Just get done as much as you can for the sales demo, even if it's throwaway code. We'll make time to redesign and optimize it later.
Posted by: Mike Lunt | July 07, 2010 at 11:39 AM
What about the old “It works in our environment” – a timeless classic ;)
Great post Don!
Posted by: Sean Bordner | July 07, 2010 at 02:23 PM
I suppose you are trying to be funny, but maybe you should stick to subjects you actually know something about. I don't go around writing about lies VCs tell like 1) Entrepreneurs value my insight and experience.
Posted by: Gabe da Silveira | July 11, 2010 at 01:13 AM
The biggest lie I hear over and over again is "I'm refactoring the code", usually from developers who don't even know what that means
Posted by: Jason Gorman | July 11, 2010 at 08:18 AM
I can't tell if you're purposefully baiting developers. Frankly, your list sucks and I hope you do a better job next time.
"I could do that in a weekend," I can't remember the last time I said this. I would use it as a derisive comment as in "his code sucks so back I could have done that in a weekend!"
"It's completely modular" I suppose I can't fault you for saying this, but it really sounds like you're using a very precise version of "modular." It's modular usually means it's reusable in many contexts.
"With the product debugged, we need to go back into the code and speed it up." I'm not sure why you think it's a bad idea to create something that works and then make something that works better. I can think of several industries where this actually works well; like ALL OF THEM!
"I was here working until 4am." what the developer is really saying to you; "you suck at appropriately scheduling a task and I had to be here till 4 in the morning fixing your screw up." To top it all off you don't even believe the developer. Next time why don't you stay till 4am while they work? I will point out that I'm actually at work right now; I haven't taken a day off in two weeks (by my own choice). I read this post in the morning and it's been bugging me all day. So yeah, I'm taking a 10 minute break to respond.
"We need to tweak the UI (User Interface)" or it could mean "Because I actually take pride in my work I took the time to watch how users interact with the software and I see some places for improvement."
"Trust me, it will work for the demo" I suppose there are several scenarios and I can't fault you for being upset by them. If it's demo code and it's a demo than it's probably best you run through your demonstration before hand. If it's production code, you demo and it fails you need a new developer.
"It is the server or bandwidth" I know I'm saying the obvious here but if it really IS the server or bandwidth then there's nothing wrong with highlighting the point of failure. If it's NOT the bandwidth and it's not the server then you need a new developer. When I see a problem I always assume I'm at fault until I can confirm otherwise.
"His or Their code is crap" Your explanation comes off wishy-washey. According to your title this is a lie we often tell. It sounds like you work with some pretty terrible developers and that's soured your opinion of developers in general. I work with a small group of developers and they all write great code, we review each others code, we ask questions and point out better ways of doing things.
Posted by: Sarvin Coachbuilder | July 11, 2010 at 06:24 PM