EDIT I was in the moment when I wrote this, and I was angry. He does care about quality, but sometimes I just don't understand the big picture. Thank you for the responses, people. You have very good points. I think when I understand the big picture better and feel more ownership in the company, I won't have such a hard time with this.

My boss (a proprietor) is a developer like me. He comes, however, from a C background and severely lacks knowledge of the benefits of proper object-oriented design. That, or he simply ignores them.

So my co-worker developed this feature prototype in a week, and it's not release-ready--at least not from a good code standpoint. It works; it does the job--but it'sa freaking prototype. It's totally not scalable.

My boss wants to wow clients and "just get the feature out." I understand that. But, we could take two weeks to finish the project, or we could take three to finish the project AND do it so that it's scalable.

I just KNOW we are going to want to add onto this feature in the coming months, and then, a customer is going to "need it in a week," and so even though we've agreed to refactor when we want to add onto the feature, IT WILL NEVER HAPPEN!

This ALWAYS happens. I'm the code quality assurance guy, but my boss seems to see me as a radical and thinks I just waste time, whereas I actually am trying to follow good, known solid design patterns. He just wants his stinking feature though, and he doesn't want to spend the time or money to do things well. He pretty much listens to what I have to say, and then he ultimately just makes the decision to take the shortest path (which cuts corners a lot).

I often develop large, important features for our software. THOSE THINGS TAKE TIME! They're not happy with the time it's taken with past projects, though, but the features I've put in all work really damn well and are very scalable.

How do you all deal with this kind of situation?


The all caps shows this is giving you a lot of stress - something that is probably best dealt with seperately (and by someone more qualified then a bunch of equally high strung programmers).

On your other front you've got two choices.

Since you are not the boss, it is still ultimately his decision to go for the short term profit at the cost of long term gains. What that means to you is that you need to make the ownership of that decision clear.

Most people will suggest that you require your boss to sign off on this kind of thing - a piece of paper saying "my employee objects, but I'm doing it anyway so when it blows up it's my fault". In practical terms this is a poor solution as it means going up against someone you are already intimidated by and deliberating creating a confrontation. A more subtle approach is needed.

Since you are the QA guy, you should have a structured procedure for how development is done (esp. if you need SOX compliance). My suggestion would be a development checklist - a worksheet that ulimately shows how each part of a feature has been completed and signed off (i.e. "requirements documented by x, testing done by y"). It's then just a matter of structuring it so that there is an obvious "jump" to go directly from prototype to out the door feature, with a sign off for when this or other steps are skipped (i.e. skipping formal or regressive testing because the feature is an urgent fix).

The second option, if you want to help the programming community at large, is to roll up your boss in a carpet and throw him off a bridge. With enough participation in this method you can help affect an industry wide improvement in code quality and customer satifaction.


It's called technical debt. http://martinfowler.com/bliki/TechnicalDebt.html And it's not always good or always bad.

If you have a solid business plan, it's OK to go into financial debt. The most savvy investors will even help you go into that debt by giving you money. They know that if you have a solid business plan, and a schedule to pay back the debt, then everyone will be better off in the end.

Treat technical debt the same way. It might be OK to take a "loan" from your code quality to get a feature out quickly or make a sale. As long as you have a plan to pay that debt back.

If you have no plan, you aren't any better than the person who pays off credit cards with other credit cards. In the short term you get a lot for free. But in the longer term you're totally screwed.


Unfortunately, in the real world short-term cash flow trumps long-term code quality considerations. Your boss cares about the cash flow, as he's supposed to, and you care more about product quality, as you're supposed to, but you do need to worry about cash flow as well. This sounds like a small company you work for and you need to "walk a mile in your boss' shoes" to see the big picture.

Your boss is trying to make a sale and make sure you and he get paid. He's probably acting cavalier about code quality but is in reality as nervous about the implications as you are. That said, he is doing his job. He needs to move product to keep the company afloat. Your job is to get the code as good as possible and the fast feature turnaround is one of your challenges.

This is an age-old challenge. Many books have been written on it.

The only thing i can suggest is that you put on your entrepreneurial hat and try and establish a middle ground with the code. Get it good enough and then out the door. That's how you get paid.


Perhaps you can compromise ... release a 'demo version' that your boss can use to wow the clients, and in return extract a promise from your boss to give you time to do it the right way for the actual release.

Note that 'making it scalable' might indeed be something you could put off until a later date, IF the first users of the feature are only going to be using it on a small scale. If it needs to scale right away, however, you should point out to your boss that having your system fall over in production is not going to make your customers happy.


Your boss is your boss.

All you can do is present the situation to him the best you can; advantages and disadvantages, on the short run, on the long run etc.

At the end of the day he makes the call so you can't fight that (at least he listens to you before he says no:)).

Just make sure you don't get blamed if he makes the call, forgets about it and a few months later all crashes in the head of the quality responsible (you). Document everything.


For the person that suggested planting bombs in the code, fuck you. Anyone who does that doesn't deserve to get paid for their work. Go work for Symantec and code viruses in your free time. You do the best you can in the time given. That type of shit can blow up in you, your boss', and your company's face. OP wants guidance, not a lawsuit.

I'll suggest the OP a couple choices.

A) Go find a new job - your values and the bottom line don't fit there

B) Carefully put together a risk assessment that correctly estimates where this poor little app will fail and list the steps to fix it. Don't waste too much more of your bosses time with this though. You already seem like you are risking being seen as inefficient. You need to build trust and this work is all yours.

Your boss is getting money in the door by seeming to move mountains for clients. The client pays your boss. Your boss pays you. Your boss had better believe that you are balancing THAT with pedantic worship of architectural theory.

Also. Those clients will have bought into your demo system. If they ever achieve "scale" they are likely going to be in contract with your company for the next go-round. That's profit, again, for the business. Once again, think of what your boss values. If you don't like the ethics of his or her business, the... go work on your own.

If the demo app meets the criteria for sign-off, it's good enough. If the client wanted more, they need to ask for it. If you can show that spec won't be met, you'll get your week.


Do what you love , love what you do.

Your boss is happy to sell "bike" then don't suggest him to sell "Benz"


This question exudes 1 of the key reasons why I believe 90% of all programmers deserve to be cockpunched, including a younger version of myself. Your entire rationale of why it's important to have 'good' code assumes that you need these proported qualities of 'good' code.

"It's not scaleable". Quantify. How scalable is it? More importantly, how scaleable does it need to be? In what timeframe does it need to meet those scalability goals, ie will it hit it's capacity faster than you can release the next version? If not, why sacridice time to market for 0 marginal gain?

"It will be hard to maintain". You won't have anything to maintain if you don't have customers. Also, what is the expected lifetime of the product? Somethings simply don't need to be maintable because their useful life is only a year or so. Also, it's probably not as hard to maintain as you think. If you are building a library, it needs to be factored well because changes you make affect many people. If you are building an application, changes you make only affect that application - i.e. damage from mistakes is greatly mitigated versus library code. Also, can you accurately predict what parts of the application will really be changing in the future and require the greatest amount of abstraction? Abstraction and the complex designs that are often required to engender it aren't free in time or brain cycles. You need to discount your design efforts because of the fact that you will not be 100% accurate in encapsulating what is most in need of it.

There are times when code really does need to be 'good'. Most business applications are not one of those times. Really most arguments from junior developers about 'good' code are almost strictly based on your own aesthetic sensibilities and not the realities of why you are creating the code in the first place.


If you are in QA in a shop like this, I don't see why you have a problem, since all the QA has been determined to be pushed onto the customers. ;-) Assign all bug fixes to the programmer responsible and you're done.

If the boss doesn't want to do up front quality management, you'll have to invest in good root cause analysis and bug-fixes and customer support. If the boss is good at anything in the business milieu, presumably he'll see the costs of support rising and get the hint that perhaps he needs to reduce costs by investing in quality (it comes for free, apparently, actually).

If he's not, apparently you've actually got two problems.

Ultimately, life is too short to prop up a bad boss - it's not your responsibility to make up for his shortcomings for your entire life - move on.


Chad Fowler in his book Passionate Programmer, gives a tip that "Be the change you want". If you find something to be insane, try to change it piece by piece, making sure the code works. Once you have progressed, you can show it to your boss/colleagues. Even if they disagree, you are doing your role.


You need to try to explain to your boss the ROI of clean code. People in that situation only care about finances.

Explain the concept of bad code debt. If you write this and get it out the door now, it will be full of bugs and issues that will have to be resolved later. And then further explain that most likely it will cost more money to fix the problem than it would to make sure it doesn't happen in the first place.

I'm somewhat in your shoes now and am trying to move people along at a slow/steady pace. Start with something like StyleCop - work your way up to code reviews and eventually over time you can change the culture.

Good luck! You're going to need it


Don't compromise your integrity. Bend but don't break. Cover your ass and most importantly, your team members. There are some things you can't change. You either lead, follow or find another role! ;)


This might not be the best advice...

After having this same thing happen with a particular boss in the past, I would intentionally code "horrible crashes" in areas in the demo that didn't detract from the wow-factor. Then, I could point to those as indicators that it really was going to take three more weeks instead of one...

I didn't like doing it and have since moved on, but after getting called out for the third time about demo-ware failing in production and no one caring about the email documentation I had, I didn't know what else to do...


My boss sounds like yours. Working is as good as done, and they will worry about any problems when they surface, not when they are identified.

In a way, it?s good business sense. You have something that you can deliver, so deliver it. I tend to view it as being more expensive in the long run, but what do I know?

If your boss is like mine, he probably never reviews your code and relies on you to tell him what the status of the project is. If so, what I do is keep them in the dark. I never tell them something is working until I feel it is completely polished. If I need more time, I make up some story and buy some wiggle room. Sometimes I?ll sneak in and rework some code I feel can be done better, and slip it in when an unrelated bug fix is required.


Is enforcing adherence to "proper object-oriented design" part of the QA position description? If not, you need to either ignore this lack of adherence, or get consensus from your boss that it become part of QA testing. If the software in question meets QA requirements and goals, it should be fine regardless of its abstract object orientedness.

Now, from what you describe it doesn't meet the QA goals; but the goals it meets have nothing to do with "proper object-oriented design." They have to do with scaleability and (I assume) performance. In the workplace environment, those QA goals are your leverage and your proper concern. When going to your boss with your concerns, phrase them in terms of QA requirements. "If this goes out as is, we'll have half a dozen priority customers file level 1 bugs within a week! Let's take an extra few days and fix that scaling issue" will go over much better than "This code doesn't meet textbook design patterns that customers don't care about."

Note: making "proper object-oriented design" mandatory will not be popular with the rest of the software development group, at least not until everyone can agree on what constitutes "proper object-oriented design."