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?
You could tell him that all of the quick-hack programming will probably come back to bite him in the butt, and unless he gives the programmers more time, your company's reputation will probably suffer in the long-run.
when salmon are outlawed, only outlaws will have salmon
It could be worse...they might get a consultant to try and impose "quality" or "six sigma" or some other BS. That's all happy flap for managers to feel better, and to feel like they're doing something to improve quality in products. The deadlines never change...or if they do, they get shorter.
They decide how much money they put into developing quality. The customer decides whether to buy the product or to go with a better product. All you get to do is find someplace cool to work. If you have fun where you work, stay. If not, don't. Maybe there are moral issues about programming hack jobs, but that's up to your conscience.
The best thing you could do would be to start up your own company if you think you could make more money doing things your way.
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 --
Tell him to hire aditional people, you have too much work load and you cant be perfectly sure that everything is going to work perfect, because you have to much to do.
With a large customer base, once the complaints start coming in management (and everybody else) starts to realise that it is no fun supporting a low-quality product.
I'm not guarenteeing that everything will magically change overnight, but if you can propose a chunk of work that can be done which doesn't visibly add value; but will help keep a large number of customers off the phone, then you might be listened to more than now.
You might want to consider getting some QA in place (if you dont have one already). Also, there is a series of books published by Microsoft Press (Yes Mickey$oft!) called Software Development Classics that can probably help. The books are: 'Debugging the development process', 'Dynamics of software development' and 'Software Project survival guide'. The most useful being the second mentioned by Jim McCarthy who has plenty of sagelike advice, some of which will certainly be useful in your conversations with this project manager you mention.
? 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
Tell the manager to take a first year engineering course called "ENGR 107" , in this he will learn about Total Quality Management...
These days, management can't afford to be idiots. Us programmers and engineers are slowly taking up the ranks in management.
Or if you dont want to do managment, go into consulting, they'l listen to what you say and pay you for saying it..
I'm in a similar position... I knew when I took the position the objective was to get the site out as fast as possible to maximise the profit. The better I do this the more favourable my pay review. It would be nice to spend longer and develop more elegant methods of doing things and allow for future expansion of the site and clients business. But I knew not to expect that when I came on board... If you do not like your job, and you think you can find another, better position (there have been a lot of posts on /. about the unemployed latly) take the high road, but do it tactfully, it pays not to burn your bridges...
just my 2 cents anyway....
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.
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...
That's a problem that I've never come across. The management team at my place now are excellent - they realise that pushing a release out before it is ready will only come back to bite us. I've worked on releases before that have slipped by over 9 months, but I work in an area where scalability, stability and reliability are vital - if we don't supply it, our customers will go to another vender. I guess that helps to focus the management team a little. ;-)
Even though working on a product that slipped 9 months really sucked, I'd much rather do that than face the support team after releasing it on time.
Going to management and telling them that from tommorrow code is going to take n-times longer to develop so the general level of quality will improve isn't something they will like to hear.
One of the XP mantras I believe in is refactoring, which tends to make code stronger the more often its changed. Every time you need to alter one of the "pre-written pre-used" routines, take a look at the design and sort out any issues you see. Whilst this approach isn't going to radically increase quality on day one, it will have a cumulative effect without dramatically increasing the timescales on what is to be delivered.
have you seen these guys?
welcome to the gnu economy.
Viva LA Revolucione
...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.
Someone actually *complaining* about code reuse!
"Look at me, I invented the stove!" -- Ben Franklin
You might want to reconsider the my way or the highway approach, especially with all the unemployed techies out there. I wouldn't try it this way unless I had another job waiting for me.
"It's not a war on drugs, it's a war on personal freedom. Keep that in mind at all times." Bill Hicks
Don't knock software reuse in and of itself. If you can build a truly top-notch adaptable library to do what your company does, that in itself is 95% of the coding work. That'll allow you and your fellow software engineers more time to actually determine and meet your customer's needs.
On the other hand, do too good a job in making the library and you may find yourself fired because you're no longer needed, assuming that you're nothing more than a coding monkey...
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:[.]
Send me a list of the web sites. I'll email the owners at various randomly selected times over the course of the next 30 to 100 days with the message "Your web site sucks!".
now we need to go OSS in diesel cars
First off: managers don't like ultimatums. They usually won't give in just for the sake of not giving you implied "change this or else" power to be used at a later date as well.
Secondly, while you may be unhappy with the quality of the product, your opinion does not matter from a business standpoint. The only opinion that matters is the customer. If the customer is happy with the quality of the product being produced, you'll have real trouble effecting any change. I've been in a similar situation and I'll bet most of us have, deal with it or walk.
Microsoft Wheel 3.6 for Pack Horses
"Look at me, I invented the stove!" -- Ben Franklin
It's a question of convincing the right management. In my experience the idiots pushing the "time to market" BS tend to push it just long enough to overcommit the next development cycle, make a bunch of promises, collect the commission, and move on to a new position. Leaving those of us in the trenches to bring some substance to the vaporware some idiot MBA promised to a customer.
I firmly believe there needs to be a tighter commitment from management to an individual product. Product development is carried out one cycle behind the sales cycle. I realize there is always a need for fresh capital, but the "sell-then-develop" model is a dangerous game. In my experience, when management realizes it has over-extended, it simply "transitions" to a new product, and lets development take the hit
Senior management, the people who have a stake in the company, need to hold middle management more responsible for quality. They also need to realize that without MBA's are replacable, an experienced developer is much more valueable.
As someone whose primary job it making things work more efficiently, I have to tell you that sloppy code is the way the world works. Get it done, get it out there, fix it later if there is a problem.
Maybe in acedemia programers have the time to achieve loftier goals, but in the business world elegance isn't very valuable.
I'm sure that there are places you could go where you'd be able to write programs the way you like, but I'd make damned positive that you'd found one before you leave your current job for what is admittedly a "philosphical difference".
Kind thoughts do not change the world
All in all, bring it up, say that you would like to see better quality work get done and your willing to do it. There is a very good chance they will tell you to get the hell out of there office and get back to work ...
until (succeed) try { again(); }
I have to say that the more fuss you make and the more noise you can produce the more you're appreciated in a corporate environment. If you always say: "That's the way to do it, no other way can be allowed, you stupid minions" With a firm and steady believe in your point of view, you will become a manager. Even if the noise you're producing is really noise, with a S/N of 0!
;-)
Intelligent people will question there own beliefs and point of view, often sounding a bit un certain, because they comprehend they only grasp a small part of the complete picture. These people, who are almost always right in the long run, are neglected and are told to work harder and in even stupider circumstances. Humble as they are, they do so.
Anyway, the best thing to do is to follow you're gut's feeling. If you are a competent guy, you'll always find a job. It's a pity that market has been made sick by noise producing entitites who think theu are IT people because they can fire-up a HTML editor.
Am I producing noise or what?
It sounds like your biggest complaint is the lack of planning/architecture invested in projects. Do you have clients coming back to you after 6 months asking for modifications which are difficult to implement due to poor planning? Do you find older projects fragile & difficult to maintain?
If so, inform your manager that the reason you're seeing these problems is a lack of initial planning & quality control, and that the only way to avoid these sorts of long-term headaches is to invest more time up-front. Ask to be involved in initial project cost/time estimates, and explain why the extra time you estimate is necessary for creating a product which will be maintainable & stable. Suggest that your company adopt official coding conventions (set by all developers, not just you) and well established development cycles. If management isn't completely clueless, they'll understand the value of these suggestions. They may not be able to implement everything you want immediately -- it takes time to get out of the vicious cycle begat by poor quality software. Still, if they take your comments seriously, it's probably worth your time to stick it out and help make improvements as you go.
If you aren't experiencing the problems described above, you're probably better off finding another job -- you aren't going to convince management that they need to change proven development methods.
I think you should take a moment to read some books on quality, and what it is. Quality is not necessarily perfect, bug free code, or being the best.
One way to define quality is meeting the customers expectations, at the lowest possible cost.
You might also want to take a look at some of the thoughts on extreme prograaming (XP) at extremeprogramming.org. In XP, the customer is always allowed to set two parameters out of four: the cost and schedule. The programmer is then allowed to define the scope of what is achievable in with the defined resources, while the fourth parameter, quality, is set to 100%.
Anyhow, in most cases you can achieve better quality without adding to costs just by changing the way you work. And if the costs are kept down, then your boss should not have anything negative to say.
Sounds like your company is getting as much business as it can handle. You seem mostly to be upset because you end up doing the same things day after day.
In this situation the only way you are going to do anything different is if you can convince management that you can improve scalability (ie service more customers with less effort) with some a new development effort. But remember if you are going to make what you are doing now easy enough for someone less talented (hint: less expensive) to do then you might find yourself out of work if the company doesn't want to explore new products.
Brian Macy
The small company that I currently work for seems to take the same stance. Our final product for each customer is very customized, but that has us adding a bunch of fields the database that only one customer will you. All of the other customers end up with either a default value or NULL in those fields. This isn't a huge problem when you only have 10 customers, but at some point we will have hundreds of customers, which will lead to a ton of unused space and greater inefficiencies in our database. Am I missing a simple solution to this problem? Or do I keep adding fields to get the job done and worry about efficiency down the road when it finally becomes a problem? Any incite?
Pretty stupid idea. If you dont like the job or the work you do, quit. You should not tell other people how to run thier business (Unless they make a product that is harmful or the by-product is)
If you don't like the product, then don't buy it, or in this case, make it. Besides, they can replace you in the drop of a hat. Things are slowing down and there are plenty of people out there that want a good job and don't have one. The company will simply replace you and get someone else with less demanding tastes.
In smaller companies it get worse than that. They are subject to violent external swings, and very often there is little correlation with how good you are and the business results you get. So sometimes it is very difficult to prove that what you are telling everyone about quality actually does lead to business results. Sometimes it doesn't and that doesn't mean that you were wrong.
In the end, however it is a simple and clear cut fact that you cannot actually run a business by focussing on the bottom line. Because the bottom line is the end result of too many variables. Too much is hidden. Improved profit can only come about through improved processes, and you cannot improve processes if you do not understand them. So that means getting into the habit of measuring all sorts of stuff, and then knowing what to measure and what not to measure and how to measure it in the right way. And the traditional methods of accountants are not always the best ones.
Then you have to make a ruthless decision. What things am I going to ignore so that I can concentrate on the important stuff. And then - by what method will I decide what is important? And that depends on who the customers are, and what they care about, and what's the state of affairs at the moment and in what processes. And that's where the vision bit comes in.
Its a system thing, again. The system can't work unless everyone in the system understand the aim, and understand the part that they have to play.
And then you have to ask "how will I know before I get to the end if this is improving or not" and "and how will I test my assumptions along the way". Without these things the so called "bottom line focus" is hardly more than reliance on luck, or worse, a way of pressuring or blaming people who are only doing their best and in dire need of leadership.
Hell I changed my mind, I'm not gonna sit here and write my thoughts. pay me.
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.
I'm in basically the same situation. My work (lead web developer) is basically to slap together entire web applications from a few conversations and "make it do kinda the same thing as this other one we've done" directives.
The usual process of making a site before I started work there was to copy all the pages from one site, and edit them until they worked for the new one. No design documents exist. Any attempt I make to reduce workload and improve quality by using standard software-development techniques gets chucked away by the MD whenever a minor error crops up.
I am also thinking about leaving my job, because work sucks when you are constantly fixing errors and behind schedule because of bad management. Basically, if you don't enjoy your work any more because of this, let your boss know you will be looking for work if the situation doesn't improve.
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
Sounds pretty damn stupid to me. You have a paying job with a secure company with more business than it can handle.
Unemployment is at a 30 year high. Tech workers and programmers are becoming more and more replacable. The economy is on the brink of a recession.
I would apologize to my boss for my stuid ass comment. Remind him that I love where I work and I love the work I do. Then count my lucky stars I have a fucking job.
Quit being a cry baby.
Let software quality make your products stand out from others, not features. There are many "elitist" companies in every industry that use this tactic. Take the Leica camera company for example (I'm into photography). They make some of the simplest featureless cameras in the market, yet they are the most expensive cameras in the market. Why? Because people don't buy their cameras for features, they buy them because of quality.
You can do the same thing with software. Make it nice and simple, but make it stable and fast. Take the basic and most important features that people use all the time, and make them work the best they can. With a good solid base system, minor features can easily be compensated for or even forgotten.
Outdoor digital photography, mostly in New Engl
Object oriented programming is NOT the answer to everything. Linear mode code, when properly written, has never failed.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
Nobody wants to be stuck in one of those cookie-cutter 'hook sql databases up to web sites using VB' jobs forever. Decide what credentials you need - academic or professional - and work towards them.
Trying to singlehandedly change the company as a programmer is a hopeless proposition. If it's a good company, they'll want your opinion. If they want it, they'll ask.
Also, consider that your management may be correct. More quality might be a waste of money, if you are in effect manufacturing confetti. If so, look for jobs that demand a different quality/cost compromise.
If you're confident you can do better and really intend to leave unless they start making changes, good for you. Otherwise, threatening to leave is dishonest and places you at risk.
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'.
Well, if the pre-used fuctions are such hacks, maybe you should bring the problems with them to your boss' attention, possibly suggest a remedy or that it is in your best company's best intrests to delevop better code? If they say no, then it's their loss, if that hurts them then it's their problem.
I am not a professional programmer myself (although I am working towards it) but alot of projects I work on for personal enjopyment i start with a code base I have pre-written, whether it be an application shell or possibly some Perl code that deciphers URL character codes for a CGI script....it saves time by allowing you to concentrate on the specifics of the program you're currently writing, not on the details of doing things you have to do every time. Maybe the code you're working with isn't flexible enough? Or is too specific? If it's really becoming a burden to use it then it's usefulness if probably costing you and your company more time than it's worth, prepare some info and ask your boss to consider a re-write or even some time to debug/optimize. If it REALLY bothers you that much, ask to take the code home with you and touch it up in your spare time, at least you'll win points with the company, and you code will be better, evenif it makes you the biggest brown-noser ever :-)
CAn'T CompreHend SARcaSm?
One thing you might try is to suggest that management charge for "extras" whereby the customer can somewhat pay for quality, or at least explicitly decide against it. For example, charge for some things like "Developer Documentation", "hours of QA", or certain "Robustness Guidelines".
That way, you can be assured that you're not pulling one over on your customers, and your management can be happy that they're able to sell extra services.
Why are you letting these clowns ruin our country?
You should continue to work there until you become financially independent. It's reasonable to leave a job if the company is abusing you, but putting out a product as fast as possible is what they're paying you for. Satisfaction isn't part of the deal. If you can support yourself, then you can do what you want, but otherwise you have a job to do. Alternatively, you could become a prostitute, and support yourself that way, allowing you to write quality code during the day. Or, you could deal drugs, or become a thief. But prostitution is likely to be more fun.
On the other hand, some owners get bamboozled by their own management -- and that is really bad news for everyone (except the managers) because frequently the owners of such businesses are themselves, of a solid technical background -- and that appeals to customers that are vitally interested in quality. I've seen this happen to some of the best who become successful -- they lose touch with their technical roots and luxuriate in the warm fuzzies provided by their own management -- typically made up of raconteurs with advanced degrees in some technical field and usually a claim to having actually accomplished something -- even if only the authoring of a book on management (which is exactly what happened to the Xanadu project, BTW -- one of the key aspects of that history that Wired Magazine didn't report on in "The Curse of Xanadu").
However, there is a more insidious dimension to mismanagement of software engineering projects that is one conceptual step beyond "The Mythical Man Month":
The Mythical Line of Code
The idea that "a debugged line of code" is some sort of measure of productivity, as posited in TMMM above, is the last refuge of the incompetent software engineering manager who is still trying to build an empire at the expense of the business owners.
I won't start a flamewar by getting into programming langauge debates, but suffice to say that in software engineering, a corollary of Occam's Razor applies:
"One should not multiply parse tokens beyond necessity."
By minimizing parse tokens, within the constraints of necessity (ie: schedule, budget, efficiency of execution, etc.), the true underlying theory of the code becomes more comprehensible and therefore more impervious to security exploits and hidden bugs. Indeed, it is such code that approaches the semantics of a specification as oppposed to its compilation.
Seastead this.
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?"
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 don't think it's the developers job to demand quality. That rests on the shoulders of the client/customer.
Ask yourself this, if your company was to offer higher quality than what it currently provides, at a higher cost (since higher quality means more time/resources spent on the project), how many customers would be willing to pay the higher cost?
For the customers that wouldn't be willing to pay the higher costs, the reason is that the current level of quality is sufficient. It's a simple matter of cost/benefit and the law of diminishing marginal returns. A lot better quality doesn't mean a lot better performance.
Everything doesn't have to be great. Sometimes (perhaps most of the time) it just has to be functional.
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.
This is a common problem. This issue plagued me early in my career. Some may disagree, but I'd suggest always writing the best code that you reasonably can, even if this means doing some unpaid over-time. You'll find that given time, people will come to recognize and respect this work ethic, and you will be able to move on to opportunities where you have more leverage to do things the 'right' way. OO can help. Concentrate on developing robust modules, which can be re-used. More work up front, but you will be building yourself a valuable tool-chest to carry with you throughout your career. There is an old book called 'Code Complete' by Steve McConnel which still has a lot of relevance to this issue. Good luck.
Explain the quality issues to your boss.. but remember: He is not in business to write shining examples of software; he is in business to sell the product/service you are working on.
Unless the 'lack of quality' starts hurting the bottom line, there is no reason to change the way things are going. In fact, it's more reason NOT to change them.
If you can demonstrate, in financial terms, how taking longer on each project to increase quality will cut down on support costs or something, you might have an angle.
Otherwise... you can only strive to do the best you can in the time you are allotted.
In my company, we try and design products nobody in his right mind would ever install. We design features that not only is it plain nobody is going to ever stand for, the account directors won't even agree to expose their customers to. We recode working products just to comply with latest fads and buzzwords. We've lost at least a year in the past four doing this.
If your company is interested in providing working products for customers, you're way ahead of the game.
That being said, I'm not quite sure what you're referring to when you complain about lack of quality. Do you (1) feel that projects are pushed out the door so quickly that you are forced to design them poorly and not test and debug enough? or (2) feel that you are doing the same tasks over and over again with no opportunities for learning or advancement?
For (1), I think that this is a legitimate concern that you can talk about with you manager and co-workers. Make sure to point out to your manager that it ultimately costs more in the long run (for you and for your customers) to have to play catch up and keep fixing bugs than if you were able to take the time and do it right the first time.
For (2), this is more a professional advancement question and also something that you should address with your manager, especially at performance review time. Ask for opportunities to work on new projects and learn new skills. Maybe your company will let you take a course or train toward a certification. You should also definitely take the initiative yourself and try to find new opportunities to grow in what you do, and show your boss that you are improving yourself.
Good luck! And if all else fails and you leave your job, let me know--I'm still looking for employment :).
Often I have found that by putting in a few extra hours in the early days to build a good toolkit, and simply doing it the right way, the first project or two take a little more time maybe running over the 'official' deadline a little - but often management puts that down to you being new - familiarising yourself with company procedures et cetera, not a big deal, particularly as you have good face time (i.e. are working long hours). But after that, once you have laid the foundation and have the tools you need, all succesive projects become faster, and are completed mysteriously ahead of deadline, and pretty soon _you_ are the star performer, as if nothing out of the ordinary had happened.
Everyone is living in a personal delusion, just some are more delusional than others.
First, remember that business is about profits. As much as we would all love to puch out the best quality work we can, sometimes market conditions dicate that we push the product out to market more quickly than we'd like... You may hate it, but it's just a fact of life.
Second, if quality is that important to you, and since you are already reusing code, why not take a little time to improve pieces of that code little by little. An hour here and there spent improving pieces of code that you use to push out sites quickly can make a difference over the long haul. This may not be as fun as custom designing code for each project, but work isn't about fun... Also, by improving the pieces of the code in increments you will improve the quality of all of the projects you work on. This is also a good way to get on your manager's good side. Trying to fix the problem bit by bit will always beat belly-aching about it.
Finally, you want to try the my way or highway approach, go ahead. You will get fired. Not only is the market tilted in the manager's favor now, but he will probably drop you on principle. For years we were held hostage because it was impossible to find people. Now that the balance has tilted, expect us to put up with less shit...
It's been a couple of weeks since my last analysis of slashcode's deficiencies. We've all seen the evidence of Taco's totalitarian methods. Now let's look a little deeper at his incompetence and short-sightedness as a coder. To paraphrase Taco's words to Anne Tomlinson, was he dropped on his head at birth?
Part 1: Why is Slashdot the only site on the internet that DOS's itself?
I'm sure you've all noticed the frequent protracted outages over the last couple of weeks. Many have demanded an explanation, or at least an acknowledgement that something has gone wrong. Slashdot has been down for hours at a time, but the editors act as if nothing had happened. Since Rob "Cmdr. Whitewash" Malda and friends aren't willing to open up to their readers, it's up to me to give you the dope on why Slashdot is such a piece of crap.
The problem is of course, MySQL, as we have always suspected. mod_perl is another slice of the problem, with the last factor in the equation being unscaleable hardware.
MySQL + mod_perl + PC hardware = crash
MySQL has long been a favourite among people who want to set up a database backed web page, but are too cheap to pay for oracle. It has a reputation for serving up pages quickly, which it does admirably on sites that have low loads. As the number of connections to the DB increase past 50, MySQL seems to lose a lot of stability. In fact, it is not uncommon for it to crash and lose data in some circumstances.
In most circumstances, this isn't a problem for slashdot. It's rare for the site to reach more than 50 connections, however it does happen. It is at these times that slashdot has an increased tendency to experience the slashdot effect firsthand. The reason is that while mod_perl isn't quite a replacement for a proper middleware layer. mod_perl includes persistent database connections, but these are irrelevant. MySQL is known for it's high connection speed, and persistent connections don't really lift it's game much. They also don't solve the problem of handling excessive connections. When mod_perl runs out of open connections, it just opens another one. In other words, mod_perl does nothing to protect the MySQL database from overload.
The other problem is the hardware. A site like slashdot, receiving approximately 600 connections per minute should be running on high end enterprise hardware, not PC hardware. Taco has tried to overcome this with clustering, but this has limitations in an IO intensive area like running a website. PCs are not known for having good network performance, and this is one area that cannot help but cause a bottleneck, particularly when the site is running under load. One advantage of running on Sun or IBM hardware is that you get good IO performance combined with the ability to utilise multiprocessing. Running your site spread over 12+ low-end machines in a network just isn't anywhere near as good.
Compare slashdot to any other high traffic site. Amazon.com for instance. Have you ever seen amazon go down for four solid hours without being DOSed by canadian hackers? Amazon copes with their load because they run a sensible database, a well-designed front-end and hardware that can cope with the load. Thanks to the open-source ideology of this site, only one of these options are open to the administrators. PostGreSQL would reduce the number of crashes, however it is about 3 times at dealing with individual connections as slow as MySQL.
Essentially, we have a situation where the site is periodically hit with a large number of simultaneous connections, and they cause the database to keel over and die. This does not reflect well on Open Source software, and puts this site in the ironic position of bringing disrepute upon Open Source though their success at evangelism. It's no wonder the slashdot editors are unwilling to acknowledge their site's incredibly fragile nature.
I'd like to make it clear at this point that I don't actually know for sure that this is what's happening. For all I know, Taco is working on the code that is running on the actual slashdot server, and keeps breaking it. I'm just making educated guesses here.
As a bonus final note to the first half of this bumper double issue, has it occurred to anyone else that this site's codebase shares it's name with a slang term for homoerotic fan fiction? Linux gay conspiracy indeed!
Part 2: What in holy fuck?! search.pl under the microscope.
I have conclusive proof that Cmdr. Taco. is a gibbon. search.pl [slashcode.com] and Search.pm [slashcode.com]. Here's something cool for you to try at home: go to the search page, and search for all comments containing the word "competent". Now wait a few seconds. Wait a few minutes. Go grab a bite to eat. When you come back, it should be done.
Yep, this is the slowest search page in the universe. If you didn't believe me last time I told you that Malda has all the coding ability of a starving five year old from Ghana, you will believe me soon.
OK, you don't need to look at search.pl. All the meat is in Search.pm, and this time it's nicely placed at the top. Find the _keysearch function. Notice the for loop in there. What that loop is doing is constructing a "LIKE" clause to insert in a query string. It surrounds every word you entered into the search field with wildcards and uses them to search against comment text and title. This is then used in the findComments function as a clause in a select query which searches the entire comment database.
I have two major problems with what Taco has done here. They are as follows:
1. Even retards are laughing at him for writing code this fucken stupid.
2. LIKE queries are slow. They are text substring searches. They can't be optimized very well by databases like MySQL. These systems simply aren't designed with this sort of thing in mind, because for applications that aren't designed by twits, this functionality is seldom needed, and best implemented in an application specific way. Let me reiterate what's going on here. Slashcode is performing a substring search on every comment and comment title in the entire database. That is, too put it mildly, a shitload of text to search through. It cannot be done quickly, as our little demonstration should have proven to you. It is an idiotic thing to implement in a web page like slashdot, and Taco should be hanged by his testicles for having even had the idea.
You're probably thinking, "Hey, wait! Doesn't google do this sort of thing all the time, with incredible speed?" Yes, google does, but google's developers actually took the time to implement data storage methods geared towards fast search and retrieval of data based on substrings. Examples of this, for those who care, would be digital search tries and ternary trees. These are the best methods I know of off-hand for implementing the type of search slashdot is providing. Evidently Taco doesn't know of them, but that's hardly surprising, since gibbons can't read or study computer science. I also doubt that they can be implemented efficiently in perl.
I didn't think I'd be able to find a clear, simple example to top the postercomment compression filter's ability to demonstrate what an imbecile taco is, but I guess I understimated him. This is without a doubt, the dumbest thing I have ever seen in code anywhere.
take the highway and see how far you get. in other words put your money where your mouth is.
Since the mid-60s, my father has been a huge proponent of Quality Assurance and Total Quality Management, having followed the teachings of W. Edward Deming long before even General Motors had taken a liking to him (Deming, not my father). Since I was very young, I knew that my father's job was to make companies make better products. Sometimes he'd cost a company a few hundred thousand dollars in new quality programs that would, in several years, pay the company back millions of dollars in decreased support or re-work costs.
I also knew that when the United States fell on hard times (relatively so, like in the 70s, early 80s, mid 90s, and now), my father would inevitably spend several months looking for a new job because the companies he worked for could no longer afford the overhead that a Quality Assurance program introduces. There was never any question of a Return on Investment in quality, but there was always the question of how much cash the Quality Programs required. What's worse, Quality Assurance is a cost center: cash flows in but revenue never comes out. Most improved processes in all parts of the company can no be directly tied to an increase in revenue or a decrease in costs, so even though people understand that Quality Assurance is something beneficial, they don't know how to quantify how beneficial it is.
Because of this, when a company needs to tighten its belt, Quality Assurance staff are the first out the door.
It's a great thing to get management interested in improving quality. There are many people who truly believe the principles that were taught by W. Edward Deming, that are awarded by Malcolm Baldridge, and that are supported by the ISO 9000 certification process, but given today's economic situation, now is probably not the right time to be bringing this up with your management.
Oh, and if anyone knows of any upper-management positions for a long-time Quality Assurance guru with an impressive track record and who's been through the ISO-9000 process many times, send me e-mail. My father is, yet again, looking for a new job in the Los Angeles/Orange County/San Diego County area.
--
The is called the REAL WORLD boys and girls. It's a world where the corporate mentality is MORE is MORE and you'll produce or hit the highway.
They don't care if you leave, the down tech sector has produced starving database programmers who are willing to take your place and readily dispense with the "quality" tripe.
I was a contractor at a major automotive plant, when hourly workers complained that the transmissions don't fit into the prescribed holes, the plant managers said "Hit it with a rubber mallet until it does line up, and do it quick so you don't fall behind".
Gotta love the corporate work quality mentality. Either quit, or sell your soul.
Hope this helps.
Your supervisors probably aren't blind, they most likely know the quality of the work being released, if they're happy with it, don't push your luck.
If the stuff you are doing is not mission critical, then who cares... your company will take the blame if it doesn't work right. They seem to be happy with the quality of your 'hacks', so why push it...
If on the other hand your code is mission critical, and your company still doesn't care that the quality is lacking, time to jump ship, 'cause when sh*t hits the fan, your bosses are gonna use you as a scape-goat.
---
Programming is like sex... Make one mistake and support it the rest of your life.
The problem with software reuse may not be that the software is bad, but rather, that it isn't just right for the new site. For example, a script that displays selected records from a database may format it in a fixed format that looks fine on the first site, but looks crappy on the second site. Now software like that isn't all that reusable, but really good software that can be plugged in well would have to handle a lot of different things that take time to put together. And if you're billing time to customers, while it may be tempting to bill one customer for the time it takes to develop something that customer doesn't really need, management won't like that when the customer says the hours were way too many for what he got. The end result is each customer is minimized and good portable reusable software doesn't happen. If there was down time available to do stuff not specifically for any one customer, then that could be used to put together good reusable software. But as long as business is coming in, I'm sure the employers want to deliver to those customers and not lose them.
I see this as building more opportunity for the future. If businesses are cranking out crappy web sites today, then in the next year or two, some site owners will eventually realize that and have to look for someone to re-design it. Thus there will be more turnover of work to come during the economic recovery. Since the economic mess was caused by the MBA types, I say stick it to 'em and let them pay for the recovery.
now we need to go OSS in diesel cars
working to.
This tends to mean ship by quarter to keep stockholders happy.
This means they don't have to ship a working product as it is easier to release a patch on the net then it is to delay manfacturing to get the fixes in.
The only way your manager is going to take notice is when the consumers of the products stop taking unfinished work.
Sadly this isn't going to happen anytime soon.
One of the best ways to approach this is to point out cases where poor quality has hurt the bottom line - time spent on fixes, lost productivity tracking down bugs, etc. to your boss. There have been a number of approaches to the issue of quality management as a means of reducing costs. Research that aspect and use it.
The reason we do things as fast as possible sometimes at the expense of quality, the reason we write for MS Windows instead of the other platforms, the reason we keep the source code instead of licensing under GPL, the reason software sucks, is all because the customer doesn't ask otherwise.
I don't know what can be done to change what they want.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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
In Fred Brook's "Mythical Man-Month" he quotes from the menu of a New Orleans French restaurant, "Good cooking takes time. If you are made to wait, it is to serve you better and to please you". If only such attitudes on quality prevailed in the software industry!
I am a SAS programmer working on clinical trials in the pharmaceutical industry. Since our work is (1) important in the proper evaluation of safety and efficacy of new drugs, and (2) apt to be audited by the FDA, quality control is an important component to our work. My management insists that proper QC procedures be followed, and we do.
My point is that programming jobs exist where quality is an important consideration. There is a great demand for good SAS programmers in the pharmaceutical industry.
Quality is a personal value and preference: if quality is important to you, consider a job such as this, where quality is emphasized.
managers (including the poster's) evaluate the costs and benefits of QA. the benefits of not pursuing quality include lower dev costs, and a shorter turnaround on investment. the costs of not pursuing quailty include customer churn, bad image, tech support costs. balancing these costs and benefits and their attendant corporate politics is probably quite tricky, so the manager therefore probably won't be that interested in being told how to do his job by someone who doesn't know how the company works (unless it's a blindingly obvious way to reduce costs - such as reusing old code ...).
Hre's another way of looking at it?
How important is improving quality to you rcustomers? If the current method produces the results they need, then you'd be wasting time and money building a higher quality product. Unless your customers are telling you they don't like the work you've done or are having numerous problems (I assume you survey your customers), then I wouldn't worry alot about making it "better." in fact, you may find they aren't willing to pay more for a better product that takes longer to deliver.
I'm a consultant - I convert gibberish into cash-flow.
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.
I agree. Don't give management a decision to make. That just gives them more power whether they say "yes" or they say "no". Instead, keep the decision making to yourself. You decide if you can do things like create better tools on your own time, or if you just want to walk. Maybe you can tell them why on the way out, but personally, I wouldn't even bother. Usually if they can't figure it out on their own, they won't understand it when explained by someone who doesn't talk MBA-speak (which I'm assuming you can't do if you asked this question of slashdot in the first place).
now we need to go OSS in diesel cars
You should read Peopleware. It has a lot of discussion on this subject and describes how quality benefits the company. Great stuff.
Honestly, I could see the issue if the lesser-quality work was causing problems with your company's business. However, you fail to present reasons why this may be the case, and hence I am unable to see any motivation for you to want to create more quality work than merely because you feel it is the "right" thing to to.
Your company's customers are ultimately paying you for your time. They get what they pay for.. if they didn't feel they were, they would go somewhere else. You don't owe them anything. There is something to be said about taking pride in your work, but, especially in this economy, you need to realize where the difference is between reducing the pride in your work and doing what is best for you and your company.
Perhaps if the shoddy work was backfiring and causing customers to leave you'd have a case, but if they keep coming, then why change what you're doing?
I suggest that you tell your boss that you realize that the work that's been getting released has not been up to par with your personal standards, and make the point clear that customers could potentially be charged more for higher quality in the cases where you feel they've been cut short. Your boss doesn't care about morals.. tell him how you can make more money by increasing quality and you get your self-satisfaction AND your paycheck.
--
Leading from the bottom doesn't work. All it
will do is imply that you know more, or better,
than your boss, and this will give them motivation
to suppress your ideas. The scenario you talk
about will end in disaster, and it will never
be recognised that pushing out quick-hacks
was sabotaging the long-term success of the
company.
That was a huge mistake. I was "talked to" by several people above me, and my superiors wondered if I was "on crack." When I tried to explain my standpoint, and how quality would improve and six-day workweeks would be unnecessary if we could produce more quality work on a consistant level across the development teams, here's what I was told:
So what it comes down to is that the profit margin is the bottom line, always, and the beauty of the insides of the machine you're building take a backseat to doing things the way they've always been done, as long as everything gets done on time.
Is it crappy? You bet. Am I comfortable working this way? Not at all. But like everyone else, I have bills to pay, and I'm looking forward to a future where I can start my own small company, and run things in a manner that I'm comfortable with. It's a sucky situation, but the more I learn about anything, the more I learn that the bottom line is always the trump card in every situation.
It's also true that the market does suck, but smart people will always be needed, and if you're smart enough, you can find a way out that both benefits your career and improves your workstyle. It may not be this week or the next, but it will happen.
Rephrase it as "Blah blah blah, or we won't be able to attract top talent or keep the best we've got."
Perl is bound to be the source of a lot of the problems too. I stopped programming in Perl about 2 years ago, and now do everything I used to do in Perl with Python. The main advantage of Python over Perl is that I can actually read my own code two days later, a feature I often found lacking with Perl.
However, Slashdot was very stable for a long time, and if I remember correctly they just did a major rewrite of their code. There are bound to be a lot of bugs to work out. I am relatively sure it will all be OK in a while. And who really thinks this is a slight to the good name of open source? I am not going to move all of my stuff over to Microsoft just because Slashdot has some issues right now. Anyway, if you think it is written poorly, and it is so adversely affecting your life, why don't you fix it instead of just being a whiny little bitch? It is open source after all, so you can if you want to.
Best Slashdot comment ever
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.
No boss can accept that you - a mere worker - tell the company to take less money! Not unless the company has so many problems that even a boss can see that something drastic needs to be done, and then it is too late!
No, you have to tell him to take less clients, charge them more so you can take the time to do things right, make more profit, and avoid all the complaints and expensive modifications and overrun schedules and/or whatever problems the boss thinks the company is having.
Or, do it all yourself! You have earlier established how long such a project takes. Now you can do the work much faster, with all your reuse and better knowledge of the systems. So, let the boss have a quarter of the advance, and use three quarters for yourself! Take an extra hour to clean up the code you are working on. Take a day to make a routine more general! Every week, add to the collection of documented tools you are using. In the end your boss is as happy, since he doesn't know you could work any faster; you are happier, as you have time to do some things right, and the company is happy, because in the end you produce better quality for the customers, who stop whining and come back for more. Probably you also end up working even faster - remember to reserve more time for the important tasks!
If none of this works for you, abandon the sinking shop! Best of luck!
In Murphy We Turst
As a person in quality assurance were I work I am not going to preach to you. There always seems to be enough of that going around on most sites regardless of the topic. IMHO
What I am going to tell you is that your bosses job is quality, if he doesn't want to pursue that course there probably isn't much you can do about it.
However , I am going to give you some place to look for help. This is a web site of the W. Edwards Deming Institute. Dr. Deming is considered the father of modern day quality assurance and the Deming web site is probably the best place to start looking or answers to your predicament.
http://www.deming.org/
Good Luck
Kevin Myers
aka
Warp1
Tracer Bullit
Spaceman Spiff
JW Black
And any body else I want to be.
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
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?
No. It would be much smarter to tell him to take fewer clients.
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.
Hand him a copy of "Zen and the Art of Motorcycle Maintenance" and explain he should read it because it will change his life. If he doesn't catch on, start looking..
Start your own business with all that good money you're making.
...All I can say is that my life is pretty strange...
No manager in the world (unless yours is really brain-dead) is going to object from hearing from you that you believe the quality of the work being done is just not good enough and that it is weakening the business, raising costs, ticking off customers and demoralizing the staff AND (if it is so) that you would like to be part of making it different.
On the other hand, most managers will not take it well if you start hinting that you are moving on if things don't change the wrong way or too early. It is better to test the waters to see what other opportunities are out there, if you think things can't change where you are to suit you, and have that next gig lined up or pretty likely before you talk about leaving. Especially in today's job market.
Good luck!
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.
... notice the uncanny resemblance to this article and the previous one on environmental friendly corporations?
I think both these problems take the same argument... What do you think?
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
do you like the job?
if yes: stay, hunker down, send email to the people concerned that you think that quality/bugs could hurt the company, KEEP the e-mail (protect your asp) because when something will go wrong it s always the person at the end that gets it.
'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
For most customers buying something, they DO NOT CARE about what the code looks like. For them, the software is a black box, they don't need to know HOW it works. They just care that it works and that its delivered on time and on budget.
Now, if the quality is so bad that its affecting the support costs or that its affecting the image of your company, take these up with your boss. Be NICE, considerate and respectful. Only a few managers will put up with serious bastard people, usually because the person is very talented.
If the job is boring you, you are out of luck, as other people are saying here, jobs are infrequent. One approach I would suggest is that you contact your local army/navy/air force recruiter. I know the defense department is always looking for good people.
If you believe the quality is so bad, then I would suggest one of two places. Try academia/research. You'll get a budget and more time than you can handle to work on quality. The other is very specialised software. Extreme mission critical software is where QOS is very valued. I know a lady that is a chief engineer for a company that makes part of a naval combat system. You haven't seen QOS till you've seen this operation. You could also try medical equipment, check with companies like Agilent. If you want more process control oriented work, check with Honeywell, AlliedSignal or GE. GE medical systems also has a great reputation for quality.
However, I would say that for what i've seen... Lockheed Martin produces some of the best shit i've seen.
However, i'd say your damn lucky to have a job that pays well. Don't sweat quality too much, just deliver what the customers want. If you have serious concerns, raise them with your manager. Don't jump your manager and go to a department head or a Vice president. Follow the chain of command.
I was hired, on a two month contract, by a web development company a few months ago. They were using a massive cheesy ASP scripts to load the clients data from a sql database and display it pseudo dynamically. The issue was, they were a small company, with one developer who admitted to me that he was a horrible programmer, which he was. It was the worst code I have seen. All variables were declared globally throughout several ambiguously named modules. Needless to say I told my boss I would be more than happy to re-write this, for free in my spare time, in COM/ASP (they hated anything unix) or perl. Well word got to the lead developer (one of the creators of the company) and I was fired at the end of the week. They told me they didn't need another developer, and were looking for graphics arts... Bah...
I am a young developer, just out of college, so this was a big blow to my already shrinking ego.
* Yes, I am a valued employee and things would really suck if I left
* I do love my job, I just wish I could spend more time making sure I do it properly.
* Yes, I agree that re-using code is good, but it's usually done for the purpose of charging for it again (something that hits my morals).
I suppose my best option, one many of you have pointed out is to simply bring up the situation to my employer. I work a *lot* of hours and many of them as to ensure the work is done right, and this usually means allocating time at home to do it, while getting other things "started" at work.
I will bring this up at our Monday meeting (tomorrow) and give some really good examples of how things suffer. Thanks very much everyone.
I agree. I don't do this for the money or for the title, I do it because I enjoy it and I do it well. The day my experieces and expertise isn't relevent, is the day I leap off the sears' tower.
Sad it has to come to that, really.
OS/2 - because choice is a terrible thing to waste.
The programmers I know who beat the "quality" drum hardest are the ones who have problems in the workplace---interpersonal problems, commitment problems, or even quality problems with their own code. It's like "quality" is shorthand for "if only the company worked the way I think it should, then I wouldn't be the goat of the team anymore."
In the words of Nigel Tufnel, "there's a fine line between stupid and clever." If the *stupid* boss is *stupidly* suggesting that all the work on past projects might have some relevance to current projects, that's simple, but not stupid. It's up to you to show how that isn't true, or that it could be true if you did things differently. Don't dismiss the PHBs so readily.
Instead of simply suggesting to your boss to take less clients, it would be better idea to suggest raising the price. It is economic theory in action; the demand is growing faster then supply so the price is raised. This should then reduce the demand (aka number of clients.)
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.
This is how things work and quanity of work generating revenue is all that the managers and above care about. Worst yet it doesn't get better. I've been in this industry for over 15 years and feel like you, but management never give more time. I keep thinking it will change and it doesn't.
My suggestion is take a little extra time, but don't jepardizing your job. At same time the more you code the faster you can code, which means in the same amount of time you can write better code. Bottom line you put out better code and gain managements respect. Then they might listen to you some, because your work is gaining them a better reputation and they charge more.
Damnit, Jim, I'm an anarchist, not a F@#$!^& doctor!
1) If you're going to tell management that you'll walk, make SURE you have a place to walk to!
2) Companies are in the business to make money. Telling them to make less money will fly like a lead brick.
3) Lead by example. Write code that you can show that doesn't need to be periodically fixed.
4) Even bothering to tell management about quality depends upon the management.
If they are reasonable people, it may fly (withOUT telling them you'll walk!!!!, DON'T MAKE THREATS!). The last place I worked at was like that, and that part was good (too bad the project wasn't going anywhere!).
The current place I'm working at is managed by a bunch of ultra-arrogant *ss*oles where the code they've written is loaded with bugs. Every day I dread coming to work to hear or fix yet another problem as our customers beta test our product. Yet one self-delusional manager still thinks we're doing great and the other blames the customer that we're general protection faulting!!!! I occasionally try to point out "the emperor wears no cloths" and hunker down to fix our product, and they think I'm not a team player... Hey, believe it or not, I'm on the team, but when we're behind 42 to 3 and it's the fourth quarter, MAYBE JUST MAYBE WE SHOULD CHANGE THE **CKING GAME PLAN... Are you actually listening managers? So at this point, I just shut up, deal with the situation, look at whatever bright areas I have left, and look for another job.
Oh well, glad I got that off of my chest. Whew!
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.
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.
To be short and frank, the end user decides if the Quality is good enough.
If the job has not warranted a 'scope' then final product is simply the customer using and being happy with your output.
If it's really bothering you find an outside interest that satisfies that part of you. OSS contributions are always nice for the 'soul'
Or you could wake up and find a life...
OK, next time I'll let some 23 year old jackass with no experience in my industry tell me what my business needs are...
start a programming project of your own at home. spend the time you want and develop to your own expectations. think of your masterpiece when your coding the drivel at work.
if you think starting your own company will give you the chance to do things right, you've got a surprise coming.
A couple of friends and I have dealt with this in a number of jobs. What we finally settled on is over estimating our project deadlines a little bit and using the extra time to improve quality. This method has worked well for us in both contract and full-time positions. Just my two cents.
http://nwbagpipes.com/
I second that, wholeheartedly.
Got time? Spend some of it coding or testing
For genuine truth-in-advertising there should also be others in the series with titles like `how to tart up rubbish and get it out the door by deadline' and `managing your wont-fix list'.
Got time? Spend some of it coding or testing
Go to your favorite video store and rent Jerry Maguire. Not the same industry, but...
-ictatha
"... the advance of civilization is nothing but an exercise in the limiting of privacy" - Janov Pelorat
Cliff posts the most boring, unnecessary posts i have ever read.
I don't doubt it at all. But in a choice between destroying my love for my profession - or even my life - and being out of work for a year or more in the midst of what will eventually be known as The Greater Depression, well, I'll find a different career when somebody's hiring again. For now I'll concentrate on keeping food on the table and having the heat on for at least an hour or two a day if possible. If it means I hate computers and people and my company, so what? I don't have the bankroll needed to speak my mind.
If you find yourself concerned about the quality of the software you're writing, you're in the wrong job.
You seem to be a programmer working a code monkey position. You've suddenly realized this when you say to yourself "the quality of my work is sucking and it pisses me off". Congratulations, you're not a scumbag.
The reality of this is unfortunate. If you complain, they're much more likely to realize that you're not the person they need either. They need someone who took a crash course in ASP and won't care about profit diminishing things like quality, or taking pride in your own work -- something that's much more important to you.
So, are you willing to prostitute yourself? That's exactly what it is. And no one will blame you for saying yes. The only person who you owe anything to is yourself.
Choose wisely.
O/O is not the answer to everything, but it is very useful in the type of software the original question was about. Web based data base apps (in my experience) are failry modular by nature and lend themsleves well to object oriented design. I have no idea what the poster beofre you works on, but if he is also working on web based database apps, I can see where he'd want to use o/o design.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
I've had miserable failure in the first part - the communications. Recently, I was employed at a firm doing XML server-side Java work, extracting data from an Oracle database, producing HTML and other formats, some quite complex for paper, CD-Rom and on-line products.
I had been employed to help boost the quality of their process, hence improve the quality of the product.
All I did was to make enemies in management. "Never mind the quality, we want it Yesterday!".
Even when projects done "my way" were consistently shown to be on-time, on-budget that was no excuse for abandoning the slipshod and low-quality way of doing things that was the norm. They didn't want speed, they wanted the appearance of speed. And I quote "A senior software engineer should be able to peer-review his own code without outside assistance."
.So when to give up? When you start getting 1 (out of 5) for your performance review (as I did), despite having the best record for projects delivered on-time and within-budget. But not until then, fight the good fight./p?
Zoe Brain - Rocket Scientist
The dotcoms would have eventually started dying anyhow. It doesn't matter HOW good or professionally grown your tulips are, if there are too many tulip growers, some will go out of business.
We have on several occations been asked to migrate binaries and or config files into production systems before we put the same code into our QA envirionment. This is simply bad practice. Why even have a QA environment if you don't plan to use it? This bit us hard last week when we overloaded our production system early Tuesday. It simply couldn't handle the amount of disk writes that were being requested and was about a half hour behind in processing orders. It didn't crash, but was just really slow at getting things done. The primary box is a 6 cpu 6GB RAM Sun UE4500, with EMC disk as the storage. Now, it is completely possible to test the same orders on our QA box. As the orders can be feed to two systems without the end user knowing. And we could have seen this coming a lot earlier. But no, management has their heads up their bosses asses. Instead of checking our code with a lot more dilagence, we throw more hardware at it. Now we have 4 cpu Sun UE3800 machines that we need to put into production, and the 4500's will become our QA boxes.. but still we will continue to do the same old thing.. write code, put it into production and then test it there.. instead of in QA!
dont risk it unless you have another job lined up. its just not worth it in this economy. be thankful you still ahve a job.
And the definition of properly written? Something that never fails.
If this question had been posted last year, the majority of the responses would have been "If the boss doesn't like it, tell him to go eff himself and find a better job." Now its all "Keep your mouth shut and be happy you can put food on the table".
Proof that we are a very adaptable bunch. Actually, the answer I like the most is "pad your estimates and use the extra time how you like" - it's not just managers that can play the BS game.
That the very concept of "debating" better quality is the basis for any uncertainty answers the question.
Flagrant disregard for quality and craftsmanship is the order of the day in way too many companies, and it is 100% the responsibility of management. It's about the number of features on the new phone system, what's on the lunch meeting menu and the huge walnut logo in the reception area, not the product.
Quality should be the first priority in development. Period.
If you really want a good argument for doing it right the first time, look at the costs needed to fix the bugs and add new features that users request.
Typically, if you are not designing the system correctly, this will be more expensive than the original construction.
Several years ago we had a
a) Crappy Netscape Browser
b) Equally Bad Microsoft IE (MSIE)
Netscape decided to redo the thing from ground out via Mozilla. I presume to do a nice architecture & best principles.
MSIE did incremental fix & incremental rewrite.
In terms of product availability, a better redone Mozilla vs a crappy MSIE (regular security alerts) with almost dominant market share.
Go figure.
Give up, greed favours mediocrity. Doing great work simply isn't profitable. Mediocre workers, mediocre products. How long has it been since you saw a real, bullet-proof, quality product?
Paul Anderson
"I drank WHAT?!" -- Socrates
Selling management on quality is a tough sell, I have found if they perceive things as working, then everything "must" be fine. When I discovered our test coverage was lacking and proposed ways to improve it, the proposals fell on deaf ears. When I proceeded to implement one of the proposals (without company support) it uncovered nineteen new page faults yet it only increase code coverage seven percent. You think with a fatal defect density that high it would inspire a quality initiative. Instead management was more concerned that it made them look bad and still would not endorse the other proposals. This was very disappointing and I left the company shortly after. Is there a company out there that wants to build quality software and is willing to put in a real effort?
"The graveyards are full of indispensable men." -- Charles De Gaulle
It's unfortnate, but it turns out that mediocrity is often the business optimization point for a given product or service. Investment in quality beyond this yields diminshing returns. Microsoft, among others, discovered this a long time ago.
If you really want to emphasize *quality* in your products, you're going to have to do a realignment of your business strategy. Right now you probably crank out websites alongside thousands of also-rans, all of whom produce sites of about the same mediocre level of quality. If you could somehow turn quality into your *unique value proposition* and sell THAT to your customers, you might have a story you can take to the bank. It will be a bit of a sell-job, though. The basic message you're selling is that "Yes, it costs more, but it won't go down when you need it most, it won't lose orders, it won't have security holes, etc. etc."
Perhaps it makes you feel better to call yourself an engineer.
But writing code makes you a programmer.
When you call youself a "software engineer" its like the janitor calling himself a "sanitation enginer".
You're not an engineer. And if you don't understand why, then you're not an engineer and you're not a programmer.
And by the way, following methodologies, and doing ISO9000 crap doesn't make you an engineer either. It makes you a mediocre programmer with a crutch. Congrats.
You can argue for proactive quality (design, testing, code reviews) if you can show it will lower backend costs. If your company is doing drive-by web sites (with no value from repeat business), I don't understand how that can be improved.
Based on your post, it is hard to tell what aspect of your projects has low quality. Where does the pain come from?
p.s. Never burn your bridges. It won't help you, it won't help your boss. The software community is MUCH smaller than it would appear, especially if you stay in the same gegraphic area.
I've been researching in Software Product Lines for three+ years by now, and all research I've read, and all research I've done myself says that re-use is beneficial for quality, so that shouldn't be a problem.
The problem you are facing could be that your re-use isn't structured enough, and that you need a solid base upon which to build the customer-specific parts.
Many companies, at least in Europe, spend lots of money to initiate a product line approach to their software development (including and possibly in particular web development companies). If your company already have this in place (intentionally or by ad-hoc), then rejoice in this and see the opportunities to create new applications faster and better (i.e. with higher quality).
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.
You certainly shouldn't bother trying to communicate with them. Start being nice to the clients, let them have your direct line, tell them you care! Then mailshot them that your starting up and nick 'em.
Start making MORE money than you are now, do better work. Winner all round. But look out for the ulcer!
I totally agree with this. There are proper geeks out there running the show in some places. They're not easy to find, and now probably isn't the right time to uncautiously jump into unemployment, but there's the odd place you can get away with quality work.
If all else fails, go earn shit money for a while, working in a place where you learn and can do quality work, then in a few years come back with a title like 'architect' and you can *decide* to do quality work.
toeslikefingers.com - because
How can a developer communicate to managers...
Keep in mind that managers, such as yours, are likely to have a different priorities. Delivering a 'quantity' bottom line is as important to management as you producing 'quality' code. Moreover, the manager is likely NOT to consider the programmer's cry for quality if there is no such echo from the paying client.
"but it's not very project oriented as much as it's become 'throw in pre-written, pre-used functions'"
Welcome to the maintenance phase. I don't know your particular circumstance, but it sounds like your project has hit a certain plateau. As a result, much of the work takes on an ad-hoc flavor. Managers love this if it's a time + labor type contract. The problem is, this can become very maddening to the programmer as he/she is compelled to write code at an unspecified, moving target. Which is then followed by fixing or modifying such code because despite the client's belief that we, actually cannot read his/her mind. At times, it is like chasing one's tail.
'The work simply doesn't stop and the more we get it seems the less we ensure quality work'
...).
... but with nothing negative to say about me.
I would LOVE to have nothing but bleeding edge work all my life. However, with almost twenty some-odd years in the industry I've learned that maintenance happens. Which is bad because it's happening to me, but good because I am the most fixable element.
Sounds like I've succumbed to the pointy-headed-boss ? Perhaps, but consider my most recent situation, which sounds similar to yours. Realizing it was going to be a bit repetitive, I built some libraries and some code generation tools. Since management only cared about getting the web reports out, I told them I needed several reporting languages on the server (e.g. php, perl, python, jsp, etc
I got about 2/3rds of what I asked for, and kept interested learning new stuff on their nickel. They didn't care, as long as the client was getting what they wanted within a reasonable time frame.
Because a portion of it was repetitive, I built libraries and code-generation for the rest of the programmers. This in turn bought the programmers on staff, including myself, time to focus on quality. Taking a bit of extra time these tools bought us to call the client and figure out exactly what they wanted before we put code to compile.
I know this sound a bit preachy. But I'm not speaking as some great genius, but rather someone who's learned from their mistakes. More than once I got myself in a jam because I didn't understand the simple reality that when I point the finger at someone else, I'm also pointing three back at me. And that since I have more control of my situation than that of my manager and my client, it's often smarter, easier and more profitable to see if it's possible to make changes on my side first.
When that's not possible, then I don't waste my manager's time with complaints, I just field my resume and leave them scratching their heads
healyourchurchwebsite.com - WWJB?
One possible opportunity that quick and dirty development allows for is a rapid-prototyping dialogue with your customer.
So you hack together the application with the customer at your shoulder; or nearby (at your site or his). Done well this produces incredible satisfaction for you, customer confidence and repeat business, and much better tuned functionality. It also keeps you much more alert during the development process which reduces the errors that monotony produces.
There are a number of hidden assuptions to this suggestion - eg. you like solving problems for people, communicate reasonably, are competent and efficient, are trusted by management and so on. But maybe your company could experiment in this direction.
I work in a small company (ab. 50 employees) that neglected quality for a long time. By now and after more than 2 years and some important (near deadly) failures , the company is on the way to quality. The principal reason for the failures was : no way at all to evaluate the impact of the decisions before they were taken (without asking the good people). It was only money driven decisions Many of us (particulary i and a workmate) were aware of the total nonsense of some decisions and the impact of these decisions on our products. For some "calm down" reasons , the CEO decided to hire a first quality manager. The objective was to become ISO-9001 (now ISO 2000) compliant (i.e. getting a better image = money :)) .
This manager did quit after less than 6 month,NO WAY TO WORK !!!!
The CEO did not let her the sufficient power to only gather the information she needed. The reason is : There was no structure at all, no processes and the concept of organizing the company respecting good sense standards was some way violating the CEO idea of its absolute control of all taken decisions.
There was another caveeat : Quality manager needed work groups for setting up company processes. And the CEO only saw the money spent by the meetings. He didn't see at all the money lost by not having structured processes at the company level.
Then a second quality manager was hired. He rapidly guessed that there was no way for us to be quality compliant in a short term.
So its first work was to give some basic quality tools (reports, ways to do) at the lower level.
Then the quality manager began to make some psychology on the CEO (manipulation is a too strong term) to slowly getting him to the idea that something was wrong at all levels, that there were another way to work and to organize the company and that without that organization , there was no way for the company to get funds from investors.
So, getting back to our sheeps , at the lower level, the Software Engeneering department was taken for the "quality experiment". And we began our first really driven project. We had no powerful tools (only 1 MS Project and noone used to it) and quite no resources allocated for the quality on the project.But with some excel spreadsheets , we built our first bug tracking system, a free UML Modeler for the design and it was already another world.
The main problem was evaluating the amount of work, and scheduling deadlines ( for the first time, the decision was given to the developers!).
The lack of experience leaded to a 1,7 factor on the expected time. Not that bad , considering we had to learn the basics of project management at the company level.
IMO,You don't have to consider quality as a "magic wand". It's long, it's hard and it has a cost. It's a company wide policy and if the high level staff is not 100% involved and convinced , the fight is already lost.
Software Quality is only the side effect of company wide quality processes adapted to the Software development.
More than tools, Quality is a question of methods and processes related to a efficient and continuous system of process control and evaluation, whatever quality system you want to take.
It needs high experimented people to drive such a transformation and a total trust between the CEO and these people.
My company still has a lot of work to become quality standard compliant but the harder is done, the CEO knows that setting up company processes is the only way to ensure a real control of the company future and to give reports that are significants and reality based.
Only after some years, there will be enough material to give a really efficient decision aid based on these reports.And the company will be able to control its future instead of rolling a dice and pray that the unweightable cost of a decision will be below the result benefit of that decision!
Quality policy gives a way to evaluate the real cost (in a global definition) of a decision and to compare it to the expected result BEFORE a decision is taken !!
But this goal can't be achieved fast, quality is somewhat the way to wisdom !!!
Don't loose the faith, and don't be aggressive.
You can't impose quality , a better way is to efficiently suggesting it and to play a game of with/without and to have really skilled people in that domain to assist you.
The solution we found was to use eXtreme Programming (XP) - a small overhead at the start of its use in setting up test harnesses, was more than repaid a little later, as the extensive testing meant that we could code faster and quality was higher.
Faster coding kept the managers happy and higher quality kept us happy!
------------ jay*arr*tee
I work at a defense contractor and a group here actually purchased rights to software...I mean, source code, kit and kabootle. Thanks goodness, it's for logistics and not for something critical. I was discussing the purchase with another worker. We work directly for the purchaser. The deal was made behind closed doors and really only with the input of one tech guy...who had a fettish for this software... and also left here but wriggled in a partnership with his new company on the way out...Anyway, my cohort made the comment that our boss (the non-technical manager type) making this deal was like someone who's never mowed a lawn buying a lawnmower. Then he added..."And they don't have a lawn either". He was right on the money!
This is rampant, not just in web development houses. Unfortunately, Dilbert has already been written...or you'd have some funny comic strip on your hands that would make you lots of money...
Unfortunately, you're right...I don't see an end to the trend!
Cheers
Galego
Que Deus te de em dobro o que me desejas
[May God give you double that which you wish for me]
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".
Your power-grab ultimatum will get you fired, or at least marginalized in the eyes of the power brokers at your company.
What you need is a strategy, a positive discussion, and not a three-option ultimatum. Point out the facts of the situation: you don't think you're doing quality work, your morale is suffering, and you think you can do better. Start talk, start DISCUSSING things with your peers and managers, and see what you can come up with.
There are a lot of possibilities to go from here. "More quality work" is vague and fuzzy. How would you achieve that goal, and how would you measure that quality?
Maybe you'll build a website toolkit which is documented, tested, version-controlled, and can be released to all sites to give them all new features, rather than madly hacked together scripts.
-- Steve van Egmond, b.math
When talking to suit types, it's important to use their language. There was an awesome suit-dude, named "W. Edwards Deming," who did a lot of work in post-war Japan. In his book, "Out of the Crisis," Deming demonstrates how quality invariably improves productivity.
The only problem here is that suits are now tuned to improving shareholder value on a damn near immediate basis. What you'll have to do is demonstrate how quality will improve short-term returns. However, the point is that there is a direct relationship between quality and productivity, which can drive profits.
Look, start looking at the company like you OWN IT!! Then tell me you don't want a larger revenue stream and more money in your pocket because you would rather spend more time coding really good stuff? Have you heard of adequate quality? If you take more time and money and over design, your competition will eat your lunch.
Sounds like you really don't know what it takes to run a company, and are stuck in your own little world. If you don't know your function and how it relates to your companys focus and direction, I agree, go somewhere else and give your boss a break, them come back when you don't know everything.
In a way, we are all working on a real-time mock up of what will really happen. It's a manifestation of the mass creative process. Push out a (rather shoddy) "envisionment" version of the future, and empower the next generation of programmers to see the prize from there.
Think of it as job security. A whole 'nother squad of programmers will be paid handsomely to do it right. Think of it as retirement security. Those next generation programmers will pay for our retirements.
This is a normal creative process, the programming need to be tightened up, and the content needs to be winnowed. The only twist is that the public is allowed to see it all.
It is sad, because most companies also have a principle of considering what an employee says, and if it gets to "my way or the highway" they probably haven't followed it. They will however follow "fire anyone who says "my way or the highway".
Life sucks, but there is hope...
From buddy's inital posting, he clearly is not happy with what he being asked to do, and at the same time feels management has imposed a harse wall between themselves and their employees.
Fire your employer - start working on getting out today. Once you have a firm job offer in hand, then you can present to your current employer ...
"The highway or my way". If your employer sucks - fire them.
The trouble is that, typically, as programmer skill/experience increases, there tends to be a desire for more order in their products. We (I'm one too) want to make our jobs easier now, and in the future, by maintaining a certain level of aesthetic in terms of the quality of the design and the code. The catch is that it almost always takes longer to get a product to market when we, software engineers/coders/developers, spend as much time on design and development as we see fit.
Managers (in the civillian sector, anyway), on the other hand, are typically interested in time to market first and quality second. This is naturally at odds with most seasoned programmer's perspectives.
However, I've always felt that the management perspective seems short-sighted. It's been my experience that almost every product that I've had to rush to market required maintenance/extension later. Said maintenance and extensions were made infinitely more painful by the lack of adequate time for design and development.
Any managers care to comment? I'd like to hear more of the other side.
...but here's what I did...
In a process I was in charge of, it took a certain amount of time to get a certain task done. Obviously as our experience grew along with the tools we wrote to help automate that task, it took less time to complete.
We just never told management we could do things more quickly now. That way they get things done in the time they expect...so they are happy...and you have time to focus on the details, or make things even more efficient, or study what you will need to know for the next phase of the project or for other projects, which kept us happy.
You just have to know how to play the game on their terms. They'll never allow you to take time away from real production to do things the 'right' way, so you have to come up with ways to allow you to do so while keeping management happy at the same time.
Hire a Quality Assurance person or team.
[Got Hosting?]
Is to calmly suggest changes, and look for consensus among colleagues(peers).
This is what you want to get across:
1. You are a team player:
a. You want to make everyone you can feel usefull.
b. You are receptive to other people's ideas.
2. You want to be sure of your ideas before you present anything to management:
a. You considered other peoples suggestions, and find reasons to follow or not to follow their suggestions.
b. Research, research, research... Look for solutions to your problems, if you can find and implement simple solutions without consulting management, it will make you look a LOT more valuable.
3. You want to be respectful of management:
a. They didn't just come in off the street and become a manager, whether you agree with their capabilities as a manager or not, somehow they earned their position.
b. If they decide not to follow suggestions, try not to be bitter, and if you want to ask them why they made the decision they did do it one-on-one.
c. (addition to b) Do not "challenge" them, especially in front of colleagues, simply present your case and assume they took it under full consideration. If you do not understand why, ask them in confidence (treat them as though they are a teacher).
This approach has many advantages:
You will look good and thoughtfull.
Everyone else will feel usefull.
Your manager will feel that you want to grow, be usefull to the company, and respect people in higher positions.
At best you will get the changes you want.
At worst it will be a learning experience: you will figure out what can be done or what cannot be done, and you can make a more educated decision on whether you want to remain in the company.
To the boss, your opinion is worth exactly 0 votes because you are not a customer. Each paying customer is 1 vote against quality. Those who walk away are voting for quality, but the boss can't and won't count those votes. There are two ways your situation can improve: 1) Customers will flock to a quality product at a pace that forces your top management to enhance quality. Too slow and they blame the economy, too fast and they lay you off. 2) You find work elsewhere. Can be difficult in these times.
Been there, done that. Believe me, all that happens is: U get Scued. With a capitol F. And the co. gets by whithout you just fine.
"throw in in pre-written, pre-used functions"
IMHO that's one of the best ways to ensure quality!
If the function is pre-written and pre-used, that means that it's also pre-tested!!
The best test for any code is to use it real-world.
My $0.02 CDN ($0.01 USD)
This is what the continual grind towards lower and lower prices has done. QC has gone - it's never coming back. Try to find some way to use machines to do rudimentary testing and analysis, there will never be a budget for a human to do it.
Look at this another way. If you were in the business of making cookies. You would want to make as many of them as possible the cheapest way possible. The only thing you have to worry about is the taste of the cookie and if someone wanted a replacement cookie just give them one. This would allow you to sell lots of cookies at a cheap price. On the other hand if you make large private jets. You would want to make as many of them as possible the cheapest way possible. However, quality becomes much more important than volume. After all you would not want to replace a private jet every time a customer complained about a problem.
It sounds to me like your boss is thinking produce cookies. While you are thinking closer to private jets. If you can figure out a better way to produce the same product without adding additional time (Your time) to the maintenance. You and your company will be better off. Good luck and do not quit before you find another job.
"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...."
You have options before quitting. I'm an old fart (42) and have fought many corporate battles (and even won maybe two). When you present the ultimatum that they either clean up their act or you're gone, they'll see you as an obstacle to making easy money.
If you want to persuade them, you'll need to show them with multiple sound arguments how they will make more $$ in the long run by not screwing their customers now.
If you're already thinking of leaving then you have little to lose. Set out a list of strategies to get them to change and identify each in terms of how much personal political capital you'll lose by attempting it. Then start with the ones with the lowest political cost and run the list. Just treat it as a hands-on college project in business administration.
Give up your own perspective. Your goal is to manipulate a small set (likely 3 to 5 people) of people and you can only do this by working through their motivations. It's safe to start by assuming that ego and greed are their primary motivators and then fill in your mental models of their personalities as you go along.
You'll need to give your project credibility so make a list of the changes you see that should obviously be made. Look hard for one or two 'low hanging fruit'. These will be one or two goals that you know, absolutely, you can succeed with in little time with little effort. Ideally, these will look good even if they are of little intrinsic value.
Every successful political power play is begun with a couple of flashy successes.
If, in the end, all fails... what the hell... you were going to quit anyway.
My suggestion is to try to fix the problems:
It's the ethical thing to do as an employee trying to look out for his/her company's best interests.
It's the ethical thing to do as a professional looking out for the customer's best interests.
It's logical for you to extract the greatest benefit from every professional circumstance before discarding it.
Good luck.
You're desire for quality is admirable, and believe me I've worked in the environment you're describing. I believe that it's rather typically in any non-aerospace company. The problem is that, contrary to popular mythology, the benefits of quality are not absolute in a business sense. There is a level of quality that customers simply won't pay for. So if you're going to have this discussion with your boss, be prepared to listen also. Quitting may be your only recourse, but be prepared to seek out a job with Boeing if you want a waterfall, TQM environment.
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.
My experience is that the companies that take quality control most seriously are the ones that have been around the longest and have the most to lose from a shoddy product. In other words, companies that actually have a reputation at stake.
The problem with most dot-coms is/was that the compressed time scale of projects put a premium on new functionality and ever-increasing revision numbers at the expense of quality. How many times have releases been pushed out the door before being fully tested, because a) the release is overdue b) the customer is breathing down mgmt's neck c) the investors are looking for progress... etc. etc...
When there is money in the bank, and when the company has made a name for itself with succesful products, then management is more likely to slow down and say "OK, we can now afford to release these products on _our_ terms, and that means thorough quality control."
Just say that it is not possible for you ethically. Your boss should then understand that you are handicapped by your morals and your brains, and take it into account for your future assignments, since most bosses dig that. They get sad that they cannot sell your ass to the most pervert clients, but they can live with it. Even whores set standards on what they don t do. Figure you are whore.
And also, don t listen to those who tell you that you are a dispensable employee. In a service oriented economy you are not an employee anymore, you are ore. And no business wants to cut in that resource. Figure you are ore.
Don't expect your boss to understand techies problem. You have to understand its business problems.
You should have a look at the agile methods, such as eXtreme Programming. The guys behind those methods have been facing the same problems as you do. They tried to find another way to organize the work, which fits the developpers (who look for quality) and the business people (who look for rentability). There are several arguments in "extreme programming explained" (Addisson Wesley, from Kent Beck) which you may use to explain to your boss that there is another way to work.
From what I understand, engineers knew about the problem and told management that it was unwise and dangerous to launch the shuttle under such cold conditions. Management didn't listen for any number of stupid reasons (money, the fact that sending a schoolteacher up into space was a big P.R. stunt that had to be well timed, I can only guess what other reasons). The shuttle blew up and everybody died -- my wife grew up in Orlando and the kids used to watch the shuttles take off from the schoolyard. She saw it happen in the sky essentially right above her head. Her words: "it was not right".
Managers: LISTEN TO YOUR ENGINEERS.
Well, you could do what I do... When your boss gives you a job, you figure out how long it will take to do the job and then go back to him with the estimate... If he says that he can give you another programmer for the job, revise the estimate up 50% for each additional programmer...
Me, "I can do that in 3 weeks."
PHB, "We can give you 3 additional programmers."
Me, "Oh, great, in that case it will only take me 6 weeks."
It's rare that you're going to find a project manager that will put quality above the bottom line. At the "brand communications" company I used to work for, we had clients like Intel and M$ and Motorola. Those companies hold very tightly to their brand as equity and only want high quality work done. They are always total cheapskates, but they expect the best and expect the job done on time. What made our organization a little different was that we had a "strategist" between the account managers and the project managers pushing for the most appropriate usage of technology and always pushing for the highest quality work. Let's face it, account managers are driven by the personal profit motive (always trying to sell the latest and greatest or PowerPoint!) and project managers are ruled by budgets and schedules. Neither are necessarily the most technically savvy types of people out there. That's where the strategist comes in and becomes an advocate for the people actually building the project as well as a quality assurance agent for the client.
The strategist allows the account manager to focus on keeping the client happy and allows the project managers to focus on keeping the project team on track and making the most efficient use of their project allocations.
Pooty tweet
That Microsoft is a good company, but that he should let you put in quality next year.
Sorry, you can't teach and old dog new tricks. And the bigger the dog is... the bigger a dog it is. Quality comes from within, it is not imposed upon from above.
Translated: if your company doesn't have an internal, automatic, innate, sense of quality, forget about it. A real company will either have bosses that unconditionally heed concerns about quality and say "go for it", or, they'll already know and you'll be doing it. Look for a new job on your spare time, and move when the time is right.
When building a bridge, the banker DOES NOT GET TO SAY "oh, use some less cable-ties here to save a few bucks". You're the engineer, they're the money-men. You engineer.
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
Why bother making quality software? Why not push out the minimum that the requirements document asks for?