125 comments

  1. Worst. Title. Ever.

    That being said you’re completely correct. I’ve worked on one too many projects where a friend/client keeps asking “Why doesn’t it do x, y or z?” The answer is simply “It’ll take too much time for barely any benefit” but the answer I give them is “it wasn’t in the contract.”

    Contracts save lives. When you’re agreeing to a project get it in writing. That way when the client comes barking for more features you can just tap the signature they provided. That way you finish on time, on schedule and on budget. You can negotiate additional functionality after you’ve been paid in full for the initial product.

  2. Great article. I’ve seen to many development projects where there is no developer representation on the team that works with the clients.

    It was like that when I worked for a dot-com just before the bubble burst. Our sales staff would tell the client whatever they wanted to hear and then come back to us and ask if the software did what they just told the client it could. This would usually be followed by a long days and night trying to get the new feature in.

    @CapnS, contracts are great if you a self-employed freelancer, but in a large corporate setting, your boss will most likely do whatever it takes to make the client happy, and the contract be damned since they don’t want to lose the account to the competition.

    1. “just before the bubble burst”

      … umm…. which bubble? I can remember at least two bubbles bursting ’round these parts.

  3. I whole wholeheartedly agree, its nice to see the thoughts that many think but seldom say published for posterity.

    It has been said that comedy imitates reality, and I was laughing my ass off…

  4. Wow! I have been saying the same thing for years now. And in short the issue comes from the top down. CEO and Execs who do not understand how or why it takes what it takes to “get something” coded, tells the sales people to “make money”. Which always leads to sales people doing whatever the client says. This all leads to lots of bugs and sacrificing of processes which will in the long run save money. Fixng a bug on production is expensive.

    So how do we fix this issue?

    Well it comes from the top CEO and Execs need to be educated on how software is created and the processes therein. Then sales people need to understand how to tell a client that it will take X amount of time and the reason is quality! Just my 2 cents.

    1. Its not about education… its about money. Its all about money.

      You can have a 1 developer star a company, become successful, hire more developers, and in time they will stop making any code. Don’t think that because they have been where you are (making code), and know what it takes that these problems will now happen.

      At the end of the day its about money, and even though they know what it takes to make software, they will as happy to cut corners has any other CTO/CEO.

  5. I can relate to these issues. I had to laugh when I read CapnS’ comment about clients asking why doesn’t it do…whatever… I have found that it’s most often because it wasn’t asked for. Maybe they were making assumptions but not voicing them. Unfortunately, clients don’t tend to know what they want until the product is finished. I wish I could work with contracts, but as Aaron said, you don’t always get that luxury.

    1. I do not think a single process is the solution. A well defined process is, and a experienced team. The problem is that the team need to get experience first… neither scrum or any other process can amend that problem.

  6. Great post.

    A guy I went to school with, now a management consultant (what the hell do they do, anyway, other than point out obvious problems & suck down dumpsters full of cash at a time?) and also a partner in the world’s largest “consulting” company, says to me every time, “Well, engineers always lie & pad their estimates, you have to watch them closely so they don’t get away with anything.”

    What a jackass. Werner, if you’re reading this, eff off.

  7. “There’s no time to run around to see whose throwing you under the bus.” ~= s/whose/who is/;

    @Karen: LOL for real. In part because I used to report to a management consultant who would, at least once a week, say, “Figures lie and liars figure.” This often occurred immediately after I showed the latest results from our instrumentation and my analysis, which was usually bad news from his perspective, reality be damned.

  8. This article is a good tribute to all of us wonderful programmers who are working day and night Building and Maintaining the application.

    I completely appreciate & Respect John Nance.

    Cheers!

  9. My biggest issue is when someone asks when it’ll be “done”. What does “done” mean? To a programmer, he might say he’s done when he writes the last line of code. He may consider debugging and testing as a separate issue. Should documentation, quality assurance, beta testing, etc. count in the estimate or no? Usually, when a programmer is approached DURING a production that has gone beyond the deadline, they take it personally and will respond as to when THEIR task will be complete and to hell with anyone else. Too often, there still remains testing and documentation and integration to be done and then the programmer is blamed yet again.

  10. A company where an Engineer, or some sort of representative of the programmer’s organization is not involved with the sales process is not a company I could work for.

    Programming is a lot like writing a novel. Often it is a creative process that requires critical thinking, and linguistic skills in order to make the machine do what you need it do it. To say you will re-write Moby Dick in a day is an impossible task — and just because a sales person sold it should not make it so. Having an engineer (sales engineer, if it were) represent those who code can at least make these demands grounded and reaonable.

    1. Analytical comment?

      You call the article “flawed” without any evidence of why you believe so, and you call it “analytical”?

      You are undoubtedly a manager.

  11. The problem is deeper than this. We’ve all heard the mantra “good fast cheap, pick two”. As true as that is it doesn’t capture an even more important fundamental problem, which is that (in the long run) you can’t manage any significant software project to both features and schedule without leading to disaster.

    You have to pick one: either it’s done on time and the features are somewhat negotiable, or the features are required and the deadline is negotiable.

    Trying to do both leads to the problem of engineers padding estimates, because the only want to guarantee both is to put a huge margin of error on each and every feature estimate in the schedule. This leads to disrespect from marketing/sales because 90% of the time you beat your estimates. So next time they multiply your estimate by 3/4, and so on, and so on, and so on.

    You may notice that these days Microsoft never says when the next version of Windows is coming out (or names the OS with a year in the title). This isn’t a PR game. They really don’t know this internally, because they develop Windows in a feature-driven process. The date is only an intention, almost never a plan. It will ship when everything that is required is done with no known bugs. Only when things get egregiously out of line (like with Vista) to they deviate from this process, and then it’s by cutting whole features from the plan and still sticking to the methodology.

  12. I’m with the agency on this one. Sounds like the programmers weren’t able to perform up to expectations, and they got what was coming to them. Hopefully their next batch can actually rise to the challenge.

  13. The title is a bit misleading…

    That being said, this article is spot on. This is why it is essential that a lead developer is high up in an organization. I’ve come across companies that have their development team(s) all the way at the bottom of the corporate ladder, and they constantly struggle (and frequently fail) to get their projects done on time. When account managers get to dictate requirements to lead developers, everyone loses.

  14. First off, I agree with virtually everything stated above.

    Second off, I do notice one guilty party isn’t being properly credited with their share of the problem: the customer. Whatever happened to ‘buyer beware’? If the acquisitions department of the customer had in its employ at least one individual who could identify a line of bull when they saw it a great deal of these scenarios would be avoided. You wouldn’t go with the contractor who offered to build you a house for what someone else would charge for materials alone would you? At least not twice… but that leads into another conversation.

  15. I was having a conversation last night about when clients will realize that they hold the power to execute efficient, effective, and smooth campaigns for steady growth. It’s funny how they’re the ones with the most to gain from a project’s success, yet they’re directly responsible for being “sold”.

    I work at an agency as a technical director, my job is to represent the discipline and support the account team’s sales mission from a technical perspective, but I’ve found that it’s really about helping producers and clients understand how they’ll screw my team into wondering if all this abstract thought is ever worth it…

    Anyone else tired of saying I told you this would happen when you told me to do x? ha!

    Really great read, thanks!

    Aaron

  16. I’ve seen this drive a company into the ground. Instead of selling the product we *had*, salesmen promised potential customers we’d do anything they asked for, for about a quarter of the actual development cost. This not only put a huge money strain on the company, but since every client had a heavily customized app support and maintenance was a nightmare. That is, when you could GET support or maintenance. The programmers were usually too busy trying to fulfill the salesman’s latest promise to fix or maintain the product.

  17. Nice post, and sadly a reality in most software projects.
    I have found, that, the more the layers involved – client manager, consultant, manager, etc – between the programmer doing the work the greater the politics. Everyone has their own agenda, and the software end up like this.
    It has become the accepted norm that a high percentage of software projects fail, when really it is due to a lack of clear communication and trust between the stakeholders.

  18. I agree the title is awful (so many people don’t read the articles) — but the article is great.

    I don’t remember who, but someone once said to me that it was just as important to manage expectations, as it was to code well. What better management of expectations, than not lying in the sales cycle about price / timeline.

    Schools need to teach how to properly estimate projects, and what a contract needs to say. Developers only seem to learn about contracts after a big contractual problem.

    The article hits it dead on, that a client only knows what he wants when a project is over.

    After a client beats down the price and timeline, they then begin drumming up the functionality and scope of the project.

    The best thing all web developers can do is to include QA, testing, documentation, and all other “other stuff” tasks in any and all estimates.

    It is valuable to write time in an estimate for functionality the client doesn’t want, if only because at the end you can say they explicitly decided against that functionality.

  19. Every time I give an estimate, I give a realistic projection of how long it will take to complete. I get hammered repeatedly. The project is then bid with whatever estimate made management happy. When the project takes as long as I originally projected, the programmers are blamed for taking too long. When I’m asked why, I show them my original estimate at which point I am blamed for “causing trouble.”

  20. I’ve worked on one too many projects where a friend/client keeps asking “Why doesn’t it do x, y or z?” The answer is simply “It’ll take too much time for barely any benefit” but the answer I give them is “it wasn’t in the contract.”

    Contracts save lives. When you’re agreeing to a project get it in writing. That way when the client comes barking for more features you can just tap the signature they provided. That way you finish on time, on schedule and on budget. You can negotiate additional functionality after you’ve been paid in full for the initial product.

  21. I think that the most important, and least practiced, part of agile methods is constant customer contact; ideally embedding one in the development team.

    We give our focus to practices test-first and pair programming. But it doesn’t matter how well you make a thing if it’s the wrong thing.

  22. Heh that’s where I’m interning right now. While it’s fun and all, I’m dieing to get upstairs and work with the analysts rather than the hardware and support guys.

    I will say, however, that I taught myself more about coding in the last 2 weeks than the last year of schooling, just from sitting there all day and solving those motherfuckers.

  23. Really great post! Not so sure about the title… but damn you’re right! I’ve been sayin’ this for years too.

    It’s just a matter of brains, how can you estimate times and deadlines if you don’t know what you’re planning??… People have to be educated on leaving things to the people who actually know.

    I think that they have to reconsider if they want to sell quantity or quality.

    Once again, great post. 🙂

  24. Why is the title of this article the opposite of what it was saying? I want to send this article to people but I’ll have to say “The article is about trusting programmers, not never trusting them” or they’ll be as confused as I am.

  25. Topic of this article, attracts business guys/user who are always against the programmers and they feel jealous, but at the end of article if they are honest they can help themselves to change their mind(s).

    It is fantastic and worth reading.

  26. Totally agree with this post. Been on death marches like this before. Always got to have a technical advocate on the sales team. At least that way there is a chance of the sales hyperbole getting balanced by reality.

    And yes, the title is extremely misleading but it jagged me in for a read. I thought it was going to be on back doors and other coder’s sculldugerry.

  27. Greetings from Reddit! I can see I’m not alone my feelings that programmers are often under appreciated and first to blame in most situations. Another complaint that I have is how, writing elegant, beautiful code is just not appreciated in the business world.

  28. Why did you put in 70+ hour weeks because someone else promised their client a golden pony? Sure, you do the best you can, but for god’s sake be a professional. Work normal hours and let them know early what will get done when.

    Compare with your housing project example. A professional house builder will give a time estimate and work on a realistic shedule. They would never work their collective asses on in silence just because the client was promised a Rockefeller center by the end of next month.

    1. Fist off, I wasn’t on that team. Secondly, I have been placed in a situation where I was EXTREMELY vocal about a project not being able to be completed in the assigned time frame. I told the project manager, 3 account service people, the head of account service, and my boss as well. NOTHING CHANGED. I literally had conversations where they looked at my, put their hands up in the air, and walked away. The advertising agency has about two programmers that work there now. They did have a team of about 20 at one point.

  29. “The more realistic they are, the more it is scrutinized from some reason.”

    The reason, is that a realistic estimate is a longer one than was hoped for.

  30. “Blaming the programmers for project failure is like blaming the goalie when a football team loses.”

    Careful, some of us are English.

  31. Great stuff! Contrary to most, I think the ironic title actually attracts more attention to the article and keeps you reading to the end in search of its justification.

    As a dev, I’ve tried to explain this stuff so many times over the years and it never gets across. If you’re working for someone intelligent, they end up realizing after a few projects that your warnings on scope, cost and schedule are spot on and as a result end up getting out of your way.

    1. I spent almost 10 years in advertising learning from people who knew how to get an audience’s attention. Maybe the title is a little risky, but after 60,000 hits and counting in less than 24 hours, I am not complaining.

  32. Firstly, great title. It has caught to eye of the audience it is aimed at. Programmers! Here’s my personal opinion, from a sales management angle.

    I’ve been managing web and software projects for about 12 years. I’ve worked with the stereo-typical coder (you know exactly what I mean), those straight from Uni and others with a wealth of experience obtained over time. I’ve seen the simplest project fail and the most complicated run as smooth as a baby’s backside.

    Well written proposals, open ongoing communication between sales and development plus managing the clients expectations. That’s the key to all of this. It is unfair that so many developers were blamed for the project in the original post. Other comments mentioning the fact that it’s a team responsibly are absolutely correct. One thing I would say is that some, not all, programmers, simply say “Not possible” without offering an alternative idea. This will frustrate the sales person involved as they are under pressure to manage the client’s expectations. They are targeted and are tasked with keeping existing customers as well as finding new ones. However, the sales person also has to understand that they are allowed to say no to a customer. They of course need to give a viable reason. However providing a solution to issues, may just clinch the deal.

    A contract or detailed proposal is a must. It gives the customer the satisfaction of knowing you as a supplier understands what is required. It also details what they are getting for their money. The programmers on the other hand know exactly what they are delivering and by when. From a management point of view a detailed proposal signed by the customer also stops any “can you just” requests. As I usually say, “Anything over and above that which is stated within the proposal will be charged for at our standard hourly rate.” I’m not saying no. I’m saying that if it is possible, based on the programmers approval, we will add it to the list of requirements. But the customer will have to pay more than that which has been quoted.

    Sales people need to communicate with programmers and vice-versa. Something that always amazes me is that the littlest request takes ages whilst something really complicated usually ends up quite a simple task. That’s why I always run a client’s request passed one of my development team first. I make no assumptions. Getting the customer to pay on time is more of an issue these days. But that’s for another post 😉

    Paul

  33. Programming is like exploring:
    One is always in unmapped territory, by definition.
    I compare employers’ requests for hard and fast “when will you complete module X?” in the same light as if an 18th century benefactor had asked: “When will you discover an unknown inland sea, or the Ark of the Covenant?”
    Exploring unknown territory is both an art, and a science, but being expected to judge *exactly* when one might hit a jackpot on a programmatical one-armed-bandit is just sheer ignorance on behalf of management just as to what they have employed you to do.
    Explorers of yore, and even contemporary prospectors are not expected to find uranium within the 14 day period set by the mining firm’s bean counters!
    That would be ridiculous! But the same accountants expect software explorers to so do.
    It is a crime executed by management, programmers.

    (Self-employed since 1971, and self-employed computer-programmer since they took up a room to themselves ~1976)

  34. Who the hell would want to be a corporate programmer anyway?

    If you’re any good at writing software, get into games/entertainment software. The world is full of middle-management kiss-asses, do we really need anymore?

  35. This isn’t the only industry where sales people do these things. When I was an electronics tech, I worked for a place that rented out test equipment. Sales people would come in and ask how long a particular piece of equipment would take to get ready. If I said it would be done by the end of my shift, they would say, “Oh, no, that has to be ready to ship in a half hour! I promised it to a customer!”

  36. Agree with CapnS, the first to comment. You need someone who can bridge the gap between marketing/customer and programmer. Someone who can communicate with programmers and have a clue about what they do and can do – what is possible. And also be able to say to the customer – Yes, but… But there’s little or no point. Or – You don’t really need that.

  37. “So what did the agency think? They laid off (fired) every one of those programmers. All the account service however, still works there. After that demoralizing death march, no one wanted to be there anyway.”

    Apart from the layoffs, I thought you were writing about my former company. Similar sounding 7 figure project and similar results.

    In practice it worked out the same, with the project barely surviving and ending up making a loss, and with all of the development talent leaving disgustedly afterwards, and the management and accounts team staying in place.

    What makes me a bit depressed about the possibility of change is that whilst I explained very clearly the reasons for my leaving (and negotiated fairly on these issues before walking away when it was apparent change was impossible), the accounts managers and sales still work the same way.

    The only difference there now is that they take on smaller projects, and they make lots of money by mis-selling them and running the development team into the ground.

    They contine to say yes to any client requests, and continue to cost projects without consulting those who must implement them.

    In some cases it seems it is possible to abuse
    the goodwill and free-time of talented people if you are prepared to accept a certain burn rate of the good ones.

    For the company, it works. For the developers, not so much.

    Depressing.

  38. Reminds me of a place I recently left. Right down to the huge project with a “[some ridiculous number]% Off!” sticker price. Developer/architect/supervisor quotes were complete ignored. Ugh…

  39. I’ve been in the programmer’s chair and have seen this too often, but unfortunately it’s not just limited to programming. In my current role in data center support, I’ve seen the same thing. The sales team has promised BMW performance and handed us a Kia budget to build the customer’s computing environment.

    Account Rep: “Why didn’t you build a geographically independent 3-tier redundant platform for that database server?”

    Me: “Because you only budgeted for one RAID-5 local attached storage chassis instead of an enterprise capable SAN we recommended.”

    Account Rep: “Well, couldn’t you have done something with open source to make it happen?”

    Me: Starts looking around for a baseball bat so I can demonstrate to him the difference between hardware and software…

    Jim

    /* If you think the problem is bad now, wait until we fix it! */

  40. Good article but I can never show it to my clients. Unnecessary use of vulgarity makes the article read-once-pass out-never.

    Too bad

  41. Tip: When your boss asks how long it will take, over-estimate. Add a couple of days or, depending on the size of it, a couple of weeks.

  42. Ensuring maximum transparency in communication process by documenting everything can change the situation. I think agile development address this issue by periodically reviewing the development.

  43. Sadly ubiquitous. This sort of thing can only be solved by good management fighting against it, and it is a fight. Even if you fire the entire sales staff and hire new ones with a sign above the wastebasket “here lies the career of those who defy IT estimates” management will still find themselves fighting this battle.

    Frankly, this sort of estimate shuffling to get a commission is tantamount to embezzlement from their company and fraud against the client. I would love to see it treated as such industry-wide.

  44. I remember early in my career attending a quarterly company-wide get together after hours at the consulting company where I had just started working.

    They were announcing the promotion of one of their top sales guys who had just closed a 7 figure deal for an application for a new large client.

    I was on the consultant staff and I spoke to my manager about it. She told me not only had he gotten a promotion he of course received a very nice commission. I asked her about the application we were supposed to develop for the client and she told me only generalities.

    Next couple of weeks we spent at the client where our mouths dropped open when we were told what the sales guy had agreed to and what we, the developers now had to deliver.

    Needless to say it didn’t happen. The sales guy moved on before things got really bad. I’m sure he climbed the ladder pretty quickly, leaving a trail of crap behind him.

    To their credit after that whenever a sales guy met with a potential client, a developer was with him to keep him in line. We never had that problem again.

  45. #1 – Sometimes you have to tell the customer NO, or stand your ground, or even FIRE the customer. You customer won’t do things for free, so why should you do free stuff for them?

    #2 – Everyone needs to be realistic, including the f*cking customer / salesman / managers. You need someone with power that has realistic expectations of what can be accomplished in some amount of time and keep the idiots in check.

    #3 – Get it in writing to stop feature creap. If the customer or sales or whome ever wants changes, then you tell them it will take X more time to do it. So you ask them if X more time is ok, along with the costs; if NO, then ask them what the want to cut so that we can add feature X. Force them to make a decision and sign off on it.

  46. I’ve seen the exact same things.

    My brother-in-law has a rule: of the three resources necessary to an IT project — money, people and time — management (including sales) can be allowed to control at most two. The IT staff has to control at least one of them.

    1. If you’re in a situation where the client said it doesn’t do “x, y and z”, the project was doomed from the start.

      Define the system behaviors, communicate them in the client’s language/domain, and include those artifacts in the contract. Those artifacts become the test cases that the customer executes during delivery and verification.

      Assuming the test cases pass, and the client says, “it doesn’t do x, y, and z”, negotiate a change order.

      Don’t blame the coder – blame the process that’s managing the contract!

  47. Wow, this is right on. I must say that even worse than your account reps saying yes all the time, is when your lead programmer says yes even though he knows it can’t be done in a particular time frame, and when he’s been repeatedly told such by all of his team.

  48. Actually, i get more frustrated at the question “what about timings?” just 2 seconds afters you set eyes on the task title… yes… because thats all i get… titles!!!

    I think i never seen an actual requirement document (good one)!

    You know, those that you read and find no “holes”, those were you have no need to ask “what if…?” and the answer is… “haaa, crap, forget it then!”

    Where i work, developer act like a last filter before we implement something. we actually are able to stop something from happen, but we need to chose our battles and so many still get in the queue.

  49. true all the way!i am a dev in Nairobi, Kenya still in campus but doing part time jobs and all the time clients come with general requirements and as you build an app as close to the requirements as possible they go on and add more requirements or change them completely. especially when they learn what a computer can do they ask some unrealistic deliverable s! as devs we should stick to the initial work plans and agreements if our trade is to be taken seriously!

  50. I was thinking I would send the URL to your article to my corporate management – could you replace the “Holy Shit” phrase with something more professional, and therefore more credible to upper level management? If so, could you then delete this comment, so as not to undermine the rephrasing you just performed.

    Beyond that, you hit it the head right on the nail. I won’t go into details, but the management at my company includes many clueless individuals, including one that wants to cancel the work I’m doing because he hasn’t seen anything yet. The reason he has not seen anything is that he has not asked to see it and evaluates programming work based on what it doesn’t (yet) do, not on what it does do.

  51. The article is awesome for some one, who’s working day and night on unrealistic projects that are agreed by greedy account managers. I personally kinda have mixed experience. While I must say the article is true in many service oriented industries, its not valid in case of product companies where Developers directly work with the client. There are lots of companies out there in market, who work closely with clients or I would say programmers interact with clients directly to make estimations. Most of the requirements are put on paper before jumping into the coding part.

    EOD its programmers life and a programmer has to work SMART and most important, as per the labor law. If some one see unrealistic estimations where you gotta unrealistic goals, agreeing on that wont be a SMART choice. It’s simple, if you don’t like something, leave that and find something that you really like. It’s a free world out there and live happy. I’m sure if you live happy you make better out of every work that you do!! My life is my responsibility.

  52. Wow, does this bring back memories, in a Dilbertesque “hey, that’s my workplace too” kind of way.

    I used to run a custom development shop in a product company. We lived and died by our estimates and lean-but-reliable process.

    I’m generally a calm person, but the only time I’ve ever yelled at anyone, professionally, was a sales engineer who a) cut our estimates by 50% before presenting to the customer and b) attempted to assist another customer with database design.

    The gall/cojones of some (most?) folks in sales is astounding. And there are no repercussions, because they can ALWAYS blame the development team.

  53. I have a couple of thoughts about this….
    First, what a client asks for is seldom what they want and if you only deliver what is asked for it will not meet thier expectation of what it was to be. (if thier expectations are not met, there are problems)
    Secondly, what the client wants may not truely fullfill thier needs. If this happens, they will feel cheated dispite having had what they thought they needed delivered.
    I guess the real trick is to be able to find out what the clients needs really are and writting a proposal that will fullfill thier needs, and convicing them that that is indeed the correct solution and educating them on what to expect from the finished product.

  54. Yes you could over estimate the time you feel you will need to complete the project but don’t forget proposals have to be competitive. Most programming based projects are calculated by time, an hourly rate. If you double the amount of time estimated unnecessarily, you might be out of a job anyway because the sales person hasn’t been able to convert any of the tenders into real work…

  55. It is tough to work and live in a world where the tail sometimes wags the dog. As a very young engineer, I once photo-copied my 3-D finite element analysis notes to the personnel department and asked if (while I worked on their (almost ridiculously long and wildly off-target) form intended for me and those those in my charge) they could provide even the simplest guess of modulus of subgrade reaction if the problem to be solved were as a simple beam resting on the ground of some unforeseen and unknown nature. I learned not to do this again, but in the end did get a break in deadline from time to time. The bean counters however would be last fired and their battle was a greater challenge, but with persistence could be worn down over time, even if I was point man and the first to go down should something go wrong.

  56. You are right. People don’t understand that coding is engineering – you have to play by the common sense or you fail. Nobody will say to builders “you know what, I need another floor” when they are finishing the roof. But when it comes to software, such ridiculous request are made very often.

  57. I agree with the basic premise of the article. I feel we should do more to get involved in the process, build trust, and help others in our business to understand what is actually required to deliver quality software.

    What I have an issue with is our industry’s willingness to absolve ourselves of responsibility for the quality of our work by blaming others. As developers, we often rationalize doing a lower quality job in the name of pressures, deadlines, and promises made by others. But it is we who deliver the software. It is we who ultimately make the decision to not test enough, not refactor, put in excessive hours, and not do a quality job.

    And every time we do this. Every single time we say it can’t be done but then deliver a steaming pile that closely resembles that which we said couldn’t be done; we reinforce the behaviors. Every time we put in excessive hours to be heroes, we set a precedent for the next time. Every time we compromise quality in order to meet unrealistic expectations, we devalue ourselves and the service we provide.

    We haven’t the right to complain about the very behaviors we enable.

  58. Great article and nice writing. You are in fact true about the fact that too many businessmen underestimate and mistrust their programmers. I see that happen every day, working in the design area and it sucks balls!

  59. Having read this I believed it was rather enlightening.
    I appreciate you spending some time and energy to put this informative article together.

    I once again find myself spending a lot of time both reading
    and leaving comments. But so what, it was still worth it!

  60. Right here is the perfect web site for anybody who hopes to find out about this topic.
    You understand so much its almost hard to argue with you (not that I personally would want to…HaHa).

    You definitely put a new spin on a subject that’s been discussed
    for ages. Excellent stuff, just great!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s