Therapy. I think that’s the best part of this web site for me – it provides me a way to get out my personal Rants and pass on Geeky knowledge; in some cases, I even get to declare certain outrageous experiences to the world. Regardless, when I started this whole thing up, I purposely planned never to attack personal Issues (person, place, or thing) too directly, because it can be problematic. In some cases, it’s about biting the hand that feeds you and in other cases, it’s so particular to my own life that no one would care anyway… in this instance, I have a very pointed Issue, but I doubted anyone would be interested. Then I realized that what has happening to me lately, might be happening to other people; this is how Dilbert got started, actually. People began to realize that the madness of the Cubicle Farm was spreading, and viola!, Dilbert was born. Having said the above, I have two Rants of a GeekStuffs nature. I feel I need to share some professional (or lack there of) experiences with my fellow Code Warriors.

Sales and Marketing. Marketing and Sales. What the fuck is wrong with these departments, when it comes to software development? It’s hard to pin it on either group individually, since both departments perform different functions for every company, and it doesn’t apply to all of the people I’ve worked with… a good number of people I know in both departments, from recent and past companies, have done their jobs extraordinarily well… the problem is that I can’t seem to clone them and take them with me to different companies! No – the on going trend, that I see, is that there’s rampant cluelessness with regards to the effort required for creating applications. Ideally, sales/marketing, when they get a request for a new product and/or feature, would check with the R&D group(s) and get an estimate on what it would take to get something done. I mean, we’re dealing with a completely intangible and often complex product, so this is no easy thing to estimate. You can’t gauge its progress, you have no idea what it might take to add the feature, and there’s no way of knowing how much testing it would take once all of the development is done.

As an analogy, say you had a three bedroom ranch-style house somewhere and you wanted to add a room to it. Because it’s visible, you could at least start to figure out where it would go and guess as to whether or not it would work – having a floating moat with the extra room is something that just won’t work, however nice it would be. Common sense tells us that, right? Now start looking at the specific details: Would you know the costs of materials? How long it would take? What if I add an extra story; would the house collapse? What the inspectors will check, and find wrong, when it’s done? Would you call a contractor, dictate your terms of work and timing and pricing? No. It’s that simple; that doesn’t happen. In most cases, you aren’t a contractor, much less a master craftsman, that can figure out all of those details on your own; you defer to a professional builder for such things. So why, as a non-programmer, would someone automatically presume to know how long a new development feature would take, much less the effort required behind it? Example? You want a new button on a dialog. OK, that’s not so bad – you figure a week. What you don’t take into consideration is:

• The impact of having to update the automated test suite, to reflect:

  • the new tab order of the controls

  • the new feature of the button itself

  • the states of the button

• The impact of updating the manual, to reflect the new button

  • Also means new screen shots

  • Online help, if any, needs updating

  • So will the web site, if there’s an online FAQ

• The time and extent for QA regression testing the entire application, to make sure the new feature/application doesn’t impact anything

  • Not just the current screen with the new button; how does that impact on anything else

  • On an embedded device, there’s limited screen size and processing and memory, etc

• What the new button does

  • More functional and integration testing here, depending on the new feature

All of the tasks above have very, very little to do with the new feature that you’re adding, per se. All of the above is impacted just from adding a button. Never mind that there’s new functionality behind the new button, too. Sales/Marketing will look at it and say “Oh, it’s just a button, how bad could it be?” Yes, it’s true. I’ve heard it, myself. In fact, a former manager of mine once said to a team of Java programmers “How long could this really take? You’re just putting images on a screen – it’s just Java!” I kid you not. I was there for that too – just wasn’t on the Java team.

The truth is that engineers have the best shot at estimating how long something will take to create and even they don’t really know. I consider the programmers with Microsoft’s OS team to be some of the finest in the industry and yet they’re always late. Why? Because they’re optimistic in their estimates? Not likely. Because nothing works the first time they run it? Hah! Or because the marketing department asked them how long, and the engineers were honest and said “18 months.” Marketing didn’t believe them, so they committed to the press for a release in six months – the product shipped 12 months late, is all.

<fact>Software is more than just coding. I wish it wasn’t, but is. There’s design involved. This helps in the long run because QA knows what the product should be doing, and from my own experiences, it helps point out little pitfalls in architecture and interaction, before you write a line of code. So it’s good all around. Software also means testing. Yes, even my own code needs it, and badly at that! Every defect that gets through you and your QA department should feel like a personal slight on your own work. Japanese mentality, maybe, but it’s the truth. Every bug that gets out the door, within my own code, enrages me. Makes me feel like I fucked up and ya know what? I should feel that way, because I did fuck up. The software world needs more testing time, overall. Software is also about billing, provisioning, and end-user experiences. That means help systems, technical writings, and charging the users that use your application. This had nothing to do with Software coding per se; it’s business practices and procedures mostly, but guess what? It’s all part of the Software process. So many software ideas I’ve had die at their creation because of the cost involved to get the project started and/or done. There’s more to Software than just coding. Business units seem to forget this, and if they do remember, the programmers some how get blamed for not getting it all done in the first place. I’ve got one application that is 75% complete – the coding is done and partially tested, but the help system, images, finalization of UI, help system, and installation still need to be done. None of that has anything to do with me, and most of it not even coding, so the application sits on my hard drive, wasted. Even as a programmer, there’s limits to what I can do with Software.</fact>

Anyway, the other part of this Rant is with regards to scheduling itself. I can say, with a large amount of pride, that for the more than 1/2 a decade, I’ve yet to miss a deadline. Why? Because I’ve been lucky enough to work with managers that are reasonable with their expectations. If I get a request for a project, and I say “two months” that usually becomes the deadline. I haven’t had management retort with “they need it in two weeks” in well over seven years. It’s nice. It’s practical and better yet, productive. I don’t know of any other programmer team that have met their deadlines with that amount of accuracy over a span of years.

Do I pad my estimates? Believe it or not, no. I’ve found out, in post mortem meetings that my bosses have padded them before passing them on to their bosses. That’s not my fault though; I just figure they’ve been burned by slipped deadlines before and want a little extra cushion – totally normal. I take a fairly good guess at what a project will take – usually the damned thing “compiles well” the first time tried, and so long as there’s a specification that doesn’t feature creep on me, I get it done ahead of schedule. Then the fun begins – QA always takes longer than they initially plan to (also normal and healthy!); there’s also unforeseen “changes” that creep in, and finally, the application is ready on time. Not early – on time. A beta might be ready ahead of schedule, but that’s just beta and pre-release – until QA says it’s done, it’s not done.

So I usually make my deadlines – admirable trait for a programmer, right? Here’s there kicker. Lately I’ve been taking a lot of shit for making my deadlines. I’m getting yelled at for being early or on time. Not rewarded. No, I hear that I’ve causing some problems recently (no big news there,) because my estimates are always too long even though I’ve been proven that they are usually an accurate assessment of the work involved. So, lemme see if you can follow this, with me:

• I give an estimate, based on the “limited” requirements I have for a project – sometimes I have none! (I’m usually told what it’s supposed to do, but that’s about it – never enough information, but at least I know that it’s not a flying car.)

• A deadline is set, based off other currently running projects and priorities

• The software is ready before or on the deadline, which vindicates the above estimate

• I get yelled at for being on time

What’s my recourse here? Say everything will be ready in two weeks and blow through every deadline? I was once a part of planning an internationalization project with a QA team of 15 people about 10 years ago, when I worked for a “shrink wrapped” applications company – they taught me that when moving to foreign languages, unless the application was originally designed with this type of requirement in mind, it could take an average application over a year to get everything component-ized, enlarged (to handle double-type characters for some languages; the US doesn’t usually care so we are single-byte for everything but Windows CE) and tested. An average application, whatever that means. When presented with a multi-platform, multi-tiered client/server application, with a multitude of client types and a hefty database (commercial grade, at least – a brand name, in fact), I figured it would be between 12 to 24 months. A wide range I know, but we could narrow it down as we got further into it. If the first road we took worked, 12 months; if we got down a path and had to start over, it gets longer from there. Logical, right? Mocked, ridiculed, and called a liar. “Three to six months is all it should take.” I kept tabs on the progress of it, because obviously I was labeled as a Trouble Maker and ignored for the rest of the project – I had to be kept away from it, less I corrupt other programmers! Before the project was dropped altogether, due to a change in requirements, it was about 1/2 of the way done with the “start” of the work, after about 8 months. Best case scenario? 16 months, give the rate of work and that nothing else goes wrong. Wait, wait… isn’t that within my original estimate? Moral of the story? Lie.

I teach a class to would-be programmers… really, I do – it’s a bit of a hobby, actually, one that I enjoy. I devote one 1/2 of one of the last classes to Software Engineering… about the problems and situations you are confronted with daily, by people that know little of programming. While that’s a normal situation, it’s when the people that are demanding the applications ignore you estimates and specifications that it becomes a Problem. And what’s my advice to them? Lie. It’s the only real defense you have. Tell people what they want to hear and then weather the heat that comes down on your head for being late. It’s the only recourse, really. After seven years of making my deadlines, I finally find myself in the snafu that I’m doing a shitty job because I’m meeting my deadlines.

When you’re reading Dilbert, have ya ever felt like you’re looking in a mirror? I do, just about every day, and I don’t even wear a tie!