Slashdot Mirror
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?
Sounds like npoole wants to change the quality of his workday, not necessarily the quality of the software he produces. While I'm sure we programmers can sympathize, I think he'll have problems getting the point across to management.
-- If no truths are spoken then no lies can hide --
? 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.
AHHHHHHH! I'm burning with goodness again!
- Reakk, Sluggy Freelance
First Try this.....
If you want to show your boss that quality is suffering look at your quailty survey history, if you have one, that will back you up. Talk to other programmers that you work with and see if they agree that quality may be getting worse.
You have to prove to them that it is a problem, most management will not cut into profits from what just one employee says. You need to have facts to back you up.
If that doesn't work try this
Are you a valued employee?
will they give a rip if you quit? If they need you then you can get away with the "My way or the Highway" bit but if not then you maybe pushing your luck. If you don't know if they value you, you will find out real quick
It's not the OS it's the user that sucks. If it's user friendly, you get stupider people. - clinko
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.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
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.
The best thing about a boolean is even if you are wrong, you are only off by a bit.
Most of what I do doesn't involve databases but networks of terminals (serial, RF, and PC UI) are becoming more and more important to us. I have just defined a general-use flat data structure that allows virtually anything to be related to anything else within the sphere of what we do, without a DB engine and very fast, and with the ability to add virtually any kind of record to an existing set on the fly. It's harder to code this than a fixed-record field for a particular customer's app, but I only have to code it once, and then I can use it for everybody. In the long run, it will clean up a lot of old spaghetti while greasing the path for new jobs.
Brackets contain world's first nanosig, highly magnified:[.]
Wow - I can't believe that you have never worked at a place that listens to it's employees. Some of the best ideas that I've ever seem implemented have come 'up from the floor'. In my humble opinion, if a company doesn't want to use the intelligence and experience that it's paying it's employees are, then it's the company's loss and they're not going to stick around long anyway.
To sum it up - make your point. The worst that they can do is say no and, at the end of the day, it is their choice to make.
You're paid to program, you're not QA.
Quality is the responsibility of everyone. Do you think you can write whatever and however you want and expect the QA department to magically instill quality into the product?
QA assure quality, they don't create it.
This seems to be a repeated theme from folks coming out of the academic world into the working world. In school, the ideals of creativity and perfection of a project are emphasized, whereas in the working world the focus shifts to making money and getting the job done. The truth is, you're probably not going to find very many employers who want to pay you to come up with high-quality, original, and "A-quality" work instead of focusing on rolling in the customers. You should probably try and channel your creative energies into something productive while still acheiving your company's goals, like finding innovative ways to roll out those websites or deal with influxes or traffic.
This is what meetings are for-- as a programmer, you probably hate them. But say to your managers, "I'm feeling pretty burnt-out here, and I think that the quality of our work is suffering. Can you see where I'm coming from? What do you think we can do to make things work better?"
Your managers are *not* out to get you, and may believe as much as you do in "doing good work." Odds are, they will react reasonably if you can communicate clearly with them.
Of course, it could be that you're just getting to the point where you know how to do 90% of your job automatically, and it could be time to make a lateral move into a different sort of programming environment that is more challenging. In that case-- say the same thing to your manager: "I'm getting tired of this work; is there some way that I could move to projects that excite me more?"
Yep. In this economy you should be thankful to be working at all. Most companies suck. They don't care about quality and many of them are so short-sighted they won't survive another year. Your goal should be to remain working, even for a shitty deadpool-bound company, long enough to see the recovery. Then, and only then, should you make a move. You have to be in it to win it, and right now taking a stand on quality, or anything else, will simply knock you out. If the company doesn't care about quality, neither should you. I've never seen a better time to be a yes-man.
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.
Read the EFF's Fair Use FAQ
The problem could be that it takes time to build this kind of good, flexible, reusable, modular components. I've done the same thing myself. But rarely can this be done on employers time (who do you bill for the time ... when there's enough work to keep everyone busy). One might try to argue to management that if they spend a couple weeks putting together some slick modular tools, that over the course of the next few months it will pay back well with even faster deliverables. But when business is rolling in and customers are saying "the other company promised it in 3 days, but if you can deliver it in 2 days, you've got the deal" then management is loath to pay people for what to them seems risky. The answer may be to put together those tools on your own time, put them on some not-well-announced project on sourceforge using a "pen name" as the owner, then come to management one day and say "Hey look what I found, I think we can use this and speed up our work. We should try this out before anyone else discovers it". And the fact that it is already out there on sourceforge would prevent them from trying to take ownership of work done on your own time.
now we need to go OSS in diesel cars
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.
Free Software: Like love, it grows best when given away.
As a rule, your mgr. hold more cards than you. It's the way the game is rigged. It's always been like that, even in the good times. Bad times just means the magnitude, not the nature has changed.
You're negotiating from a position of weakness. About the only thing you can do at this point in time is to start looking for another job. Only when you have another job offer, do you hold a stick more powerful than your mgr's. You can politely make some suggestions about how to do things differently, but be prepared to be blown off. If he's a good mgr, he'll listen and make changes. If he's not, well, that's about all you could do. At no time should you risk a direct head-on confrontation, without having something to back you up with (like a job offer).
Use this as a point to decide on what you really want to do, and where you really want to go. Doesn't sound like your current company is where you want to be at, so decide on what you want. Then start looking around for something that's closer to where you want to get to, try to get a job offer, turn in your two weeks' and leave. Be patient, be persisitent. Persistence will trump just about any other virtue.
If you want to do something completely different, now would be a good time to get training.
This is one of the reasons I refuse to do work as a developer in most cases. My professional work is systems and network administration, although my 2 decades of programming does (except in the last few months) get me plenty of calls to come interview for some programming job. Right now I have enough cash and contract work to hang on for the next 2 to 3 years, so I'm working on developing something for my own business idea. Interestingly, while I thought I'd have plenty of time to do it right, I even feel my own pressure to get it done and get it to market sooner. That is a fact of life. The concept of getting things to market sooner really is valid from a business perspective, despite how much the geek in me says that's crap. At least during the economic downturn, it's less likely that competitors are doing as much that will compete against me, so I can take a little time to get this done right.
now we need to go OSS in diesel cars
I gave up trying to use the 'quality' argument years ago... companies aren't out to produce a quality product, they exist solely to make lots of money for their shareholders.
The great mystery is how managers can shout at programmers for producing buggy software, then shout at them for missing their (unrealistic) deadlines by only 24 hours (and this is after pulling a week of all-nighters).
To management it's a simple equation - product=customers=money. Quality doesn't come into it - in the real world if a program works for 24 hours you've probably made the sale... and if it breaks after they you can charge them for the upgrade too!
So next time you find yourself in the middle of a block of 15 year old code that didn't even work then, let alone now, that management won't let you touch, take solace in the fact that every other programmer is probably going through something similar...
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:
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.
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:
But the basic form of the business case is:
Another way of saying the same thing is:
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
It depends on what you--and the customer--defines as "quality". The simple answer: "enough [but not too much]". A solution needs only the quality sufficient to perform its job; any less makes it unreliable; any more makes it less cost effective.
Can you have too much quality? Yes. Web applications typically don't need, nor can they afford, the level of quality demanded by life- or safey-critical applications. (And speaking from experience, most programmers won't, or can't, tolerate the demands of such critical development. I approached work every day with the perspective of "if this harms someone, can I state honestly and credibly to a court of law that I did everything in my power to prevent it". Now do that for a couple years; it gets very old very fast.)
Before you start in on management about "quality", have a good definition of it is you're after, what is enough, and why you think what you're providing custmers isn't sufficient.
Define "quality" before trying to make "quality" code. "Quality" doesn't mean one single thing. It can and does mean different things to different people. I've seen people use "conformance to spec", "fully documented", "feature rich", "crashproof", "fast", "easy to use", "surprising", "first to market", "bug-free" as all or part of what "quality" means.
Figure out what you mean by "quality", then find out what your boss means by "quality". You may be talking across each other. You might want to look at Gerald M Weinberg's Quality Software Management for a better discussion of the meaning of "quality". I'm not sure about the rest of the book, but the section on what "quality" means is relevant.
My other advice: ignore consultants and companies who peddle a Process (a process to reach SEI CMM level 5, or ISO 9000 status, for example) as a means to acheive "quality". They often leave "quality" undefined or vaguely defined because then they get to use opposing meanings as convenient. When convincing programmers to use The Process, quality consultants will use "bug free" or "speed to market" as the implied meaning of quality. When talking to managers, they use "feature rich", "on schedule" or "completely documented" as the implied meaning of quality. When talking to corporate leadership, the use "cheap", "speed to market" as meanings. Often, some tension exists between various definitions of "quality". "Cheap" often opposes "bug free" or "fully documented". "Feature rich" can oppose "high performance". "Speed to market" can oppose "fully documented". You get the picture.
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.
'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.
Bush's education improvements were
I agree absolutely. In my experience, it seems that the company I work for defines quality as "how much process can we make our poor engineers and coders jump through before they crack?" Quality is definitely "discussed" where I work, but rarely are the people who are most responsible for implementing quality involved. We work to a process that is so complex that it is is unreasonable and barely manageable. Do we have design reviews? You betcha! Code reviews too? Absolutely! But these are often mired in so much process, procedure, and unnecessary documentation that the spirit and intent of the *peer review* has long been forgotten. Our management seemingly has a complete, utter misunderstanding of the engineering and development process. The intent of the engineering process is to have a staged, cyclic processs of refinement where errors are detected, adjustments are made as necessary, and the product is then reviewed by a panel of peers until said product has been sufficiently developed so that progress can be made to the next phase.
Our management has done the most ridiculous thing: peer reviews have been turned into milestones, and this absolutely discourages iterative refinement. You get *one* peer review, and if your design doesn't make it through, going back to the drawing board is discouraged. The item under design is instead marked up with kludges and hacks, "accepted with modifications" and hurried on the next stage. Few peers will contribute seriously to the review anyway, because if they raise a serious issue, the process will innundate them with a ton of paperwork that they don't want to deal with. Our process does its best to discourage quality work by making it supremely frustrating to do anything in a simple, direct manner. Our peer reviews have at least 3 or 4 mandatory notifications to managers who do not contribute to the design whatsoever; also on the list of attendees are QA, subteam leads, software architects, systems engineers, interns, and occasionally even admistrative assistants.
Our well-intentioned Quality Assurance program is destroying our quality.
Dude, trowing out pre-written, pre-used functions is what good software engineering is about. That's the whole point of good design, preventing you from having to re-invent the wheel every time.
If you're getting bored, try to get higher up the design hierarchy instead of sticking in your lowly code production job.
It's a hack when you have to write from scratch essentially the same thing again and again. NOT when your are re-using stuff. Get with the program.
Even if you are cutting and pasting code, quality shouldn't go down if the code was written well in the first place. If you had made a proper middleware for each of the various languages you use for your web development, all the time you spent would be with custom content and not cutting and pasting code. Productivity would go up, quality would go up, and time and cost would go down. You would also have more time to spend on the "cool" stuff.
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.
My opinion? See above.
"...I would suggest that this economy is no longer the kind of economy that will support an employee dictating "my way or the highway"."
/Dread
I have to object to the (probably mainly Americentric) notion of a quality workspace, yes I do define two-way communication in my workplace as a "quality" parameter, to be a pure factor of the economic tides.
You are saying that during labour shortage, labour rules and during labour surplus, management rules. While I can see that it will impact it somewhat, (salary mostly, not strategic influence) it most definatly is not the one and only factor.
How about coutry/company culture, governement and plain bussiness tactics? To me it seems just as silly to let your company be run by screaming labour monkeys when there is some shortage, as it is to let it run blindly by management without labour input.
How about changing the world for the better? How about just trying to communicate BOTH WAYS first? "I hold the hammer, so I will hit your head today" is really not a good relationship.
IMHO working for a US (culture) company, compared to working for a Dutch (culture) company is/was very different in the 80's, 90's, and 00's it still is.
A whole lot different then the difference between shortage/surplus in my job-market.
Gr
The point was to emphasize that when a pizza is delivered to my house, I don't care if it was cooked in a Vulcan or Middlebe-Marby oven, if they used X or Y management style or if they were driven by this factor or not.
All I care about is that if the local manufacturer of circular pseudo-Italian cuisine:
delivered it fast enough;
delivered it as specified;
wasn't stuck to the top of the box;
didn't taste like the top of the box.
... yet amazingly enough, even in those cases, I didn't give a fig about how the restaurant was managed.
I mean if I wanted "quality" Italian, then I'd get dressed up, take the wife downtown, spend some time and some bucks
healyourchurchwebsite.com - WWJB?
Your boss wants
The trick is to find an approach which fulfils both these sets of goals. Several exist, but the most obvious one is to work over the course of several projects to turn what you have (which you say are all very similar) into an actual product. This means
Your boss gets
In addition you both get
To successfully sell this to your management you will need to be able to demonstrate that this can be done off the backof your regular project stream, and does not have to mean that some guy gets to sit in a corner contemplating his navel "writing the product" for a year. You will never sell that to your boss. Instead, devise a plan where you use the code for project A, and generalise it a bit and add customisations to support project B. By the time you have delivered C and D as well, what you have is a product.
To make this work, you will have to retain the IP on the software you write, which I guess you don't at the moment.
The best way round this is to tell the clients explicitly that they are getting a product (clients often like products because it means that the project delivery risk is reduced).
But the client will refise to allow themselves to be marooned without support. Hence you do a deal with them whereby they get a non-exclusive license to modify the code which is transferrable if the business is bought or sold. You can also tell them that this means that they are free to seek support for your code from elsewhere (but that they cannot sell the code on). They may well like this (it has several good features, e.g. insulating them from risk of your company folding). Your support agreement will need to be clear on the fact that you won't support the code if they have just hacked upon it madly.
In short: develop a strategy that benefity you, your boss and your clients, and think about hoe to sell it to all three.
Sounds like a lot of Slashdotters need to watch Jerry Maguire.
Whether you're a coder or a sports agent, the grind's pretty similar, as will be the reaction if you suggest "fewer clients for less money".
Having had this complaint in the past I finally decided that discussing with your manager can be a waste of time. The only way that seems to have a chance of working is to become your manager. If you believe that you have the technical skills to do the job better, then go for your managers job. It may result in the highway if you don't read the politics correctly but at least you can do something about it if you make it. One thing to remember though, generally managers have somebody else higher up the food chain that is saying 'No' to any request that is going too cost more than the current situation. Be prepared to write up cost analysis reports, on your own time, to get anywhere with your ideas.