On Getting Management Interested in Improving Quality?

npoole asks: "Like many of the Slashdot readers, I am a programmer and have been pushing out repetitive database content for about a year. The work simply doesn't stop and the more we get it seems the less we ensure quality work. I have been debating telling my boss that either we take less clients, less money, more quality work or I am leaving. Is this a smart thing to do? I'm making very good money doing quick hacks to push out websites, but it's not very project oriented as much as it's become 'throw in pre-written, pre-used functions'. Any advice on how to ensure quality in our work without telling my boss it's either my way or the highway?" Of course, improved quality in any product affects the bottom line, and it's the bottom line that managers are paid to keep up. How can a developer communicate to managers (both open and closed) the value of better quality in development, and how long should one try before giving up?

Comments

Re-use bad?

[bricriu]

? I'm making very good money doing quick hacks to push out websites, but it's not very project oriented as much as it's become 'throw in pre-written, pre-used functions'

Is this necessarily a hack? I could easily understand how it could be boring (as noted in a post above), but I was under the impression that being able to re-use your code across multiple projects was a Good Thing (tm) -- in order to get them out the door faster, among other benefits. Just because it's a new client shouldn't mean that you should have to re-invent the wheel.

QOS

[buss_error]

I think that I would communicate your concerns a bit less forcefully. Jobs are tight, and it might be a while before you land another. In particular, I always ask former employers if the applicant would be rehired at the old job. If they refuse to answer (or say "no"), it is a red flag to me that the applicant might be a trouble maker or undesireable. Line up another job before you walk out - that is a smart thing to do and will keep food on the table.

I see two things here: One, perhaps the boss is trying to get as much work as possible so that billing can be at a high level. Second, (s)he may have the same QOS concerns you do, but has reasons not to address them at this time.

What ever you choose to do, a calm, reasoned approch is always a better way than a hot-headed, "My way or the highway" attitude. You can leave if it bothers you that much, but don't leave in a huff. It won't do you any good and will cost you later.

profit level is hard to argue against

[devleopard]

Not an impossible task, but you need to consider your approach. As developers, we like clean, pretty code. However, the people that keep us fed like profit. Saying, "I'm a geek, I like it like this" will get you nowhere. Instead, push for quality control - some sort of lifecycle methodology (in which writing code is a small part of the overall process). Point out that 80-90% of the life an application is maintenance, not original development. By pushing for a structured development process (requirements, design, development, QA, deployment) your projects will come out clean and well implemented. Of course, the bottom line is profit - if the "extra" hours to ensure quality can't be translated into billable hours, there's no hope. However, whatever you do, DON'T QUIT. The market is sh** right now. I repeat, the market is sh** right now.

Re-orient the problem

[ansible]

First a word of advice: If you're getting paid, and the company you're working for isn't about to go out of business, then strongly consider staying where you are.

Perhaps you can approach the problem a different way. You could try talking to your boss about the issues you're dealing with; it seems the worst one is repetitious nature of the code you're working on.

Anytime you're doing something repetitive with a computer it's usually boring, and it's a sign that you're doing something wrong.

Perhaps you can work with your company to develop a more abstract toolkit for your application area. If your programming lanugage/library doesn't support abstraction very well, perhaps you can come up with a code generator.

It may be easy for you to push out quick hacks. But how easy is it to write a program that can do the same? That could be a good challenge, and it would benefit the company because they could complete projects quicker. You might also get to use some new techniques or tools.

An employee who's constantly eliminating his own job is highly valued by good managers. Not that really good managers are all that common either...

Re:well

[Twylite]

In my experience, the company's reputation does not suffer. I speak mainly of web development shops in this matter, but all to often there is oversell by the salesdroids, and there is no reasonable (sometimes even technilogically feasable) was to meet the targets.

But the company has this nice fineprint in the contract: "Quote is an estimate only; billing for actual hours worked will apply", or something to that effect. Basically everything is cool until the deadline, then the client starts jumping up and down demanding their software, which they get 100% late for twice the bill.

They bitch, moan and complain, but still come back to the company because of lock-in; not contractually, but because everyone else they talk to admits that to modify (update, maintain) the application will be difficult and costly for them without the original company's knowledge, design docs, etc (which, incidently, aren't part of the software and not purchased in the contract - bummer).

I know this goes for the UK and South Africa, and I'm sure there is at least some incidence of it in the US. "Churn it out fast 'n ugly, 'cause then they will pay more to maintain it" is the general rule. One day companies will catch on to this extortion, but they aren't at the point yet.

I know a number of damn good programmers who are simply not allowed to produce good code, because the company feels it is a waste of time. Sadly, the companys where they have produced good code have gone under in the dotcom slump ... why? Because they took longer to do the job, and (sometimes) quoted higher in the first place. The perception is that anyone who can quote can do the job properly, so you go with the lowest bidder or the most established.

/end_rant.

As a manager...

[Anthony Boyd]

...I would suggest that this economy is no longer the kind of economy that will support an employee dictating "my way or the highway". It is very likely your supervisor will pick "highway" even if you're very good, because there are many, many highly-qualified candidates now coming into job interviews. It wasn't like this a year ago. I realize other slashdotters may challenge me on that, because it's not a very nice thing to tell someone that they're possibly expendable. However, your boss may very well think that way, regardless. So be careful.

In addition, the "good salary" you claim to be getting may be due to the fact that you're churning out sites fast but charging the same rates you did back when you custom-built them. By asking to change the process, you may be getting a change in salary too.

Finally, don't forget that object-oriented, modular programming is supposed to make cookie-cutter work possible. If you're reusing your code over and over, sure, it could be sloppy, careless work, but it also may be that you've got a system working well and just object to the monotony more than the code. If that's the case, ask to be put on different projects, rather than taking a hard-core "reform-or-I-walk" stance.

Are you nuts?

[Keck]

In just about any organization you have leaders and you have workers. It sounds like your boss is saddled with the responsibility of being a leader, and you have the role of a worker. For that reason *alone* it would be well worth your time, money not to stick your opinionated nose in where it doesn't belong. Don't get me wrong, I'm on the same side of the fence that you are, but rarely does an approach like you suggest end up making any change for the better for *anyone* involved. It may be that your company makes more money doing quick hacks; in the long run if they think they can make more money doing project based non-hacks, they will. If in the long run your clients finally realize that more careful planning up front is worth it's weight in gold down the line, they will go that route too. You can't control the average intelligence around you, you just sound like the fool on the hill... trust me on this one.

That said, I think a better way to look at this is
a) ignore the money aspect (both yours and your employers) Always trust that a business will do the thing that makes it the most money. You won't change this in the near term. If the money is that important to you, you should either stick it out or try to find a job that pays similarly doing something you *enjoy*
b) If you aren't happy doing what you are doing, look for guides on the web that give professional suggestions about how to bring it up, what to do and not do, etc. with your boss. do NOT just give an ultimatum, especially not in public company
c) If in the end, after rationally sitting down with your boss and explaining your position in a professional manner, you still aren't happy with the work, and your changes don't make business sense for them (even if you still know you are right -- you can lead a horse to water and all that) maybe you should consider leaving! It doesn't do much good to be in a job you don't enjoy.

Re:Quality... for who?

[EvlPenguin]

Sounds like npoole wants to change the quality of his workday, not necessarily the quality of the software he produces.

They're one in the same. I know from personal experience that if I'm not motivated by anything more than just getting the job done, then I won't produce the same quality code that I would have under favorable circumstances. Not due to time constraints, but because there's no motivation for me to do anything more than the bare minimum. This is why I'm a programmer and not just another corprate slob; because I take pride in my work, but that's not possible when you're being treated like a code monkey.

Finding the right clients is the real key

[Infonaut]

Unfortunately, the world is not organized around the principle that quality will always win the battle against mediocrity.

For example, Microsoft is the biggest software company in the world specifically because they realized early on that consumers are less interested in getting quality than they are in getting something that meets their perceived needs.

This is an important point, because unfortunately the most important aspects of software quality are usually hidden from the end user. Since most consumers actually do realize that they don't know jack about the inner workings of their software, they elect not to get inovlved in the esoterica of which kernel is more stable or which file system kicks ass.

Let's make the assumption that your company's clients aren't consumers. Let's say they're aerospace engineers. Smart peope. People concerned with quality. But the quality they are most concerned with is the quality of their own work. So their attention is primarily focused on how well the software you build for them will help them create quality aerospace products.

Also, keep in mind that the cash that runs your client's company and your company has to come from somewhere. Cashflow can often be a huge issue for clients. If a client knows that they can spend $50k for something they know they'll get in an imperfect form one month from now, versus $100k for something that they know is more elegant more cost-efficient over the long haul, they may elect to spend the $50k because their short-term financial concerns dictate that they deal with a lower quality solution now if it will give them just enough to do what they need done.

Even if your manager understands that the quality way is better, more likely than not she'd have a tough time convincing the client of that. In fact, in my experience, clients often don't really want to hear about deep quality issues. "Just tell me the tradeoffs, and I'll make the decision" they'll say. They simply don't want to really know the nitty-gritty details. "That's what I hired you for!"

The Bottom Line is money, and if your software is good enough that your clients can make money with it, most of them will vote with their pocketbooks. Most companies simply follow the buck, from quarter to quarter.

One thing you might try is to evaluate your next employer not just on the work conditions and pay, but also on who their clients are. There are companies out there that actually think long-term. An excellent book on the subject, "Built to Last" goes into detail about the characteristics of visionary companies. Yes, it sounds like cheesy business-speak crap, but these guys conducted extensive research, and they avoid easy answers.

Find a company that serves long-term oriented clients, and you may find yourself a lot happier.

Get creative

[Stephen Samuel]

Rather than coming at the situation from the point of complaint, come at it from the point of solution. Look for ways that you can liven up your work day, AND make the company more productive (profitable).

As an example:
If your work is repetetive, this indicates to me that there is room to automate parts of it. You might talk to your boses about setting aside 10% of your time to improving the website creation software. This could make your work time more interesting and make the company more profitable.. a win all the way 'round.

What's possible is only limited by your imagination. Just remember that the easier you make the change for your management, the more likely that they'll agree to it.

Be careful what you wish for

[Prong]

First off, I highly recommend not giving your mananger the "my way or the highway" speech. Even in a good job market, it would be considred a CLM. Right now you'd be better off withdrawing 2 to 3 months worth of income and pitching it off the nearest bridge than getting in management's face.

I'm not sure what code reuse has to do with poor product quaility, unless the modules themselves are broken somehow. What you've described really sounds like a development manager's wet dream. Drop-in, pretested modules with a minimal amount of modification? That's the holy grail of the coders-as-cogs management mentality! If the customers themselves aren't complaining about quality, I doubt management is going to give a hoot what the rank and file thinks.

If you really insist on pushing this, I've got a few pointers for you:

• Send a polite e-mail asking for some time to discuss some concerns. Don't go into to too much detail, and keep a copy for yourself.
• Prepare a written document on exactly what your concerns are, and exactly why you believe these to be problems for either your customers or your company
• It's best if you can quantify the impact (x numbers of customers lost, y dollars in revenue gone), but you need to at least show a solid link between your issues and valid potential consequences.
• Be as professional and calm as possible. Going on about how stupid something or someone is doesn't impress management types, and probably gets your issues routed to the circular file pretty quickly.
• If all else fails, start looking for that new position quietly!. Getting the boot before you've gotten something else lined up is expensive and foolish if you've got the option of keeping your current gig until the next thing comes along.

Best case, management addresses your issues, and you look like a "team player". Worst case, they drop kick your arse out without even giving you a listen. The outcome depends on how you play your cards.

Go Between the Horns

[MarkOShark]

You don't have to accept poor quality or leave your job. What you need is a strategy to drive an increase in quality.

There is a trilogy of dimensions at the core of the issue: cost, time and quality. Every organisation needs to balance these. The management of your organisation, like most I have worked in, don't understand the quality issue in relation to software because it is more subjective than the other two dimensions and therefore it doesn't get the emphasis it deserves.

From the little I know about your situation, here is my take on what you need to do:

1. You need to understand the impact that the reduced quality has. Is this manifested by significant complaints from the user community; is it manifested by users switching to an alternative product:? Understanding this is important because it will become the business driver for the change you want. If you can't demonstrate that the reduced quality has an impact that matters, you won't be able to influence anyone.
   
2. Find other people in your organisation that believe that quality is also a core issue, and preferably not just from the software development team. e.g. Documentors, help desk staff, testers. Most importantly, if you can find articulate users who can reiterate your claim of poor quality, this is good.
   
3. You need to identify tangible steps that will increase the quality. You can't just say you need more time to develop because this doesn't demonstrate that the quality will improve; you might just spend more time making nicer interfaces. You need to say things like: we need to add an additional 1 hour of stress testing for every 3 hours of programming; we need to add a step in the project plan for users to acceptance test the product and allow 2 days (for arguments sake) for changes as a result of this; (insert you ideas here!)
   
4. You need to make a business case to your management. This doesn't need to be a fancy piece of work, but it does need a punchy argument so that the management will look at it and reach the conclusion that the quality issue is having an impact on the organisation. The angle you need to take will vary on your organisation and the people you are trying to influence. In a small business, the management are probably more focussed on basic objectives (e.g. profit, revenue). Larger organisations may include more complex factors such as market positioning, compliance to standards or legal requirements etc.
   But the basic form of the business case is:
   
   • This is the problem and it's impact [on whatever matters, usually $]
     
   • Here are steps that will rectify the problem and the costs for these steps
     
   • Here is how we will measure that the steps have increased the quality
     
   • Here is the business benefit that will be achieved (and here is the kudos you'll get from your peers/clients)
     
   
   

Another way of saying the same thing is:

• The only way to get the change you want is to influence the people who make the decisions on how much resource (money, people) are involved on something.
  
• You need to prove to these people that quality is important and your product doesn't have enough of it.
  
• If the quality is improved, it has the effect of improving of whatever is important to them.
  

If you have other people who have the same focus as you, pool your talents and resources together.

If you want this change and it's important to you (which it sounds like), then you need to put in some work to make the change. Don't make an ultimatum because it's an employer's market - they can just take you up on it and that won't help anyone, especially you.

Remember, anyone can be influenced if you can show them that what you want makes it better for them too.

I hope this is in any way helpful. I have had similar battles myself and still do, but life is always slowly improving!

Mark

Horse shit masquerading as horse sense - was Re:As

[samantha]

The day I have to "be thankful to have a job at all" and not speak my very experienced and bright mind as I see fit is the day I stop programming for a living. I wouldn't be worth a damn without being able to speak up and actually make a difference.

Not taking a stand, if done by enough employees, guarantees that your job, or even your entire company will be the one with its head on the block next.

Not caring about quality because your company doesn't is a most excellent way to hate your work and lose your spark utterly. Don't do it. The paycheck isn't worth what that will do to you if you take such advise. I know what I am talking about.

The problem is managers with little tech knowledge

[Futurepower(tm)]

'As a rule, I will *never* work for any organization where project management is in the hands of people who are not technically current.'

By far, the biggest problems in technically-oriented companies are the non-technically-oriented managers. They are generally making far more money than they would at a non-technical company. They are willing to do anything to keep their jobs, including making life miserable for everyone else.

The best acting I have ever seen was not in a Hollywood movie. The best acting I have ever seen was by a manager trying to make everyone believe that he could manage without thorough understanding.

When they sink their companies, they are generally able to get another job, because the people who hire them are faking it, too.

The dot-coms failed because they hired good actors and not knowledgeable people. The dot-coms did not fail because of highly complex situations that could not be understood in advance. They failed because they did extremely foolish things.

The use of non-technical managers will continue as long as there are investors who will put money into something they don't understand.

Use the right language

[ebbe11]

In order to get through to management, you have to talk their language. And that language is:

Money.

Let's face it: If you talk technical details most managers will get that blank stare after a while. Either they don't understand what you are talking about or they are not interested, probably both.

But if you can show them how to save money on the bottom line, they will listen to you. And yes, you can boil it down to money. Better code means less time spent on correcting errors, time which most likely is not billable. If that time (a.k.a. cost) can be removed or better yet converted to billable time, it will affect the bottom line positively.

So in order to be allowed to make better quality, you have to calculate how much it will save on the bottom line.

Also, be honest and don't oversell your stuff. You may think that what you propose will earn say a 20% saving. Tell your manager that the saving will be at most 10%. Why? Because you will most likely run into snags and teething troubles that will diminish the initial savings. And if you don't, well, performing better than promised is usually not a sin.