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?
...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.
My Greasemonkey scripts for Digg &
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.
A computer without Microsoft is like ice cream without ketchup.
Now, if this bothers your conscience or you just prefer to not be associated with "good enough" work, do seek employment elsewhere.
If the client hasn't budgeted for overages due to quality assurance, your boss will ignore your pleadings.
-- @rjamestaylor on Ello
I have worked for a small software shop for 3 years now, and we recently started implementing Extreme Programming into all of the development.
Ths difference has been astronomical. Deadlines are more realistic, the our releases are far more stable, and basically, the whole "chaos" of development seems to have taken on an organized form that makes everyone happy, even our extremely hyper CEO.
It's customer-driven, it's organized, and it has simplified life at the company immensely. I'm not a shill for it, I'm just relating our experience.
I would highly recommend picking up a couple of the XP books. There are several chapters devoted to how to sell the idea to your bosses, as well as recommended means for showing them how well it's working, which is essential when dealing with people who are obsessed with ROI.
In 1986 David L. Parnas and PC Clements published a paper entitled, A Rational Design Process: How and Why To Fake It. Parnas and Clements present a strategy for imposing overlying order upon the often fractured development process; the goal of which is to produce better software. Doing snippets of work for managers/clients who don't care about quality as much as they care about costs is often a cause of this fracturing.
I couldn't find a copy of the paper online, but it has recently been re-published in Software Fundamentals: Collected Papers by David L. Parnas.
Your close, the correct sequence of events is:
.... duck!
1. Identify the problem(s).
2. Collect data to support your claims, use forms, i.e. number of unitialized variables in code X on date mmddyy, etc.
3. Write your report, preferably in the form of charts. Don't forget to keep copies for yourself.
4. Submit your reports to management, 2 separate managers to create accountability.
5. for(;;)
congratulations, you are now the first member of the quality assurance team.
This way you will have an impact on the other programers. Oh yea, one last thing
Kevin Myers
aka
Warp1
Tracer Bullet
Spaceman Spiff
JW Black
And any body else I want to be.
This is a good point. You need to see - and explain - this from a business perspective. As someone else mentioned, it sounds like what you're doing is subject to automation. But when you propose that, do so not for the purpose of "prettier code", but more rapid production.
In other words, you'd be able to handle *more* clients for the same cost. In fact, you'll not only be able to handle more of the cookie-cutter stuff (which will, btw, improve in return for your form once this is automated), but you'll also be leaving yourself (and other developers) free for the non-cookie-cutter work.
It would also help if you've post-development cost factors to which you can point. There are many different forms these can take. How much does it cost to maintain the systems your clients are using, how much does it cost to add new features, how likely are clients to shift asway from your products - and therefore your company - as they grow or change, etc.
One trick I've often used is simply a special case of iterative improvement. Each time we reuse a cookie cutter, we learn more about it. We therefore improve it. Perhaps we add a feature, or make it easier to extend in a new direction, or improve the automation of cutting the cookies. The cost of this work is covered by the client, but all clients - past and future - receive the benefit of the work. That translates to your company receiving the benefit of the work.
This can actually be quite challenging. You're not just cutting cookies, but improving all of the tools used. This then takes you in the direction of better automation, etc., that I discussed above.
There's really a lot of room here for you to maneuver. But just remember to see and explain things from a business perspective. Unless you've technically savvy managers that will perform the tech->business translation themselves, you need to explain things to them in a language they understand.