On Getting Management Interested in Improving Quality? 270
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?
well (Score:1, Interesting)
Re:well (Score:4, Interesting)
In my experience, the company's reputation does not suffer. I speak mainly of web development shops in this matter, but all to often there is oversell by the salesdroids, and there is no reasonable (sometimes even technilogically feasable) was to meet the targets.
But the company has this nice fineprint in the contract: "Quote is an estimate only; billing for actual hours worked will apply", or something to that effect. Basically everything is cool until the deadline, then the client starts jumping up and down demanding their software, which they get 100% late for twice the bill.
They bitch, moan and complain, but still come back to the company because of lock-in; not contractually, but because everyone else they talk to admits that to modify (update, maintain) the application will be difficult and costly for them without the original company's knowledge, design docs, etc (which, incidently, aren't part of the software and not purchased in the contract - bummer).
I know this goes for the UK and South Africa, and I'm sure there is at least some incidence of it in the US. "Churn it out fast 'n ugly, 'cause then they will pay more to maintain it" is the general rule. One day companies will catch on to this extortion, but they aren't at the point yet.
I know a number of damn good programmers who are simply not allowed to produce good code, because the company feels it is a waste of time. Sadly, the companys where they have produced good code have gone under in the dotcom slump ... why? Because they took longer to do the job, and (sometimes) quoted higher in the first place. The perception is that anyone who can quote can do the job properly, so you go with the lowest bidder or the most established.
/end_rant.
Re:well (Score:3, Interesting)
As a rule, I will *never* work for any organization where project management is in the hands of people who are not technically current. They are a non-entity at best, at worst, they can ruin the lives of their employees. I've interviewed enough of these "manager-managers" that I find their attitude towards managing the software development personally offensive. Mostly it's focused on perserving their authority and cracking the whip over their staff. "Beat the rock harder, beat it faster, more guys with sticks! Oops, wrong rock! Beat that rock over there!" No wonder so much software sucks out there. It's even worse that in most projects, the requirements are pulled out of management's hat, and have little to do with actual customers desires. How many of you have had to re-work a piece of software because of poor RA?
Now that I've ended the rant, enlightened management is always concerned about quality, and at the very least, is running the software on a regular basis to keep their thumb on the pulse of the software, and they have a good feel for what the customer experience will be. Customers don't reject products because they're short on features, they reject them because of crashes.
I strongly recommend Tom Gilb's "Principles of Software Management", which describes phased delivery of software, and rigorous requirements analysis. It's a forerunner of "XP" which is the latest trendy book, but it seems that some managers use "XP" as an excuse for "open-plan" offices, and more shouting, and kinda forget the automated testing and refactoring parts...
The problem is managers with little tech knowledge (Score:5, Insightful)
'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.
they won't do it (Score:1, Interesting)
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.
In my experience they do care about quality ... (Score:3, Interesting)
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 ...).
It's the Company's and the Customer's Decisision (Score:3, Interesting)
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.
You had me at hello (Score:2, Insightful)
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".
Quality... for who? (Score:3, Insightful)
Re:Quality... for who? (Score:3, Insightful)
They can be very much related - apart from the "pride in work" factor, it tends to be more fun to add functionality to well maintained, high quality code than it is to fix bugs in crappy code under the pressure of customers demanding fix after fix after fix.
Re:Quality... for who? (Score:5, Insightful)
They're one in the same. I know from personal experience that if I'm not motivated by anything more than just getting the job done, then I won't produce the same quality code that I would have under favorable circumstances. Not due to time constraints, but because there's no motivation for me to do anything more than the bare minimum. This is why I'm a programmer and not just another corprate slob; because I take pride in my work, but that's not possible when you're being treated like a code monkey.
Learn from Microsoft (believe it or not) (Score:3, Interesting)
Has anyone in Microsoft actually read those? (Score:2, Funny)
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'.
Re: Learn from Microsoft (believe it or not) (Score:2)
Fortunately, it was clear to other people who actually were in control that he was talking out of his ass, too, and so I didn't have to deal with him after that. I still shudder that he (and his wife, who is even worse, but in a different way) now make their living teaching project management skills.
Re-use bad? (Score:4, Insightful)
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.
Re:Re-use bad? (Score:2, Insightful)
a) you get good code- one main codebase and some patches/extensions for each client means improvements apply globally
b) development time is drastically speeded for most clients as almost everything will have already been done (and, in the bosses terms, more money in less time with less effort).
All it takes is a bit more up front planning and you'll be sorted.
TQM (Score:1, Interesting)
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..
Its your job (Score:1)
I'm not a programmer but (Score:2, Insightful)
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
QOS (Score:4, Insightful)
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.
Re:QOS (Score:2)
I absolutely agree that you should line something up first. However, your criteria won't always work. In my case, if I left the company I work for it would hurt them severely. My boss has asked me for several months notice in advance if I was to leave. Obviously he his happy with my work, but would he give me a glowing recommendation so that I could leave, thus hurting his company? I would like to think so, but to tell the truth I can't be sure.
profit level is hard to argue against (Score:5, Insightful)
Re:profit level is hard to argue against (Score:2, Informative)
In other words, you'd be able to handle *more* clients for the same cost. In fact, you'll not only be able to handle more of the cookie-cutter stuff (which will, btw, improve in return for your form once this is automated), but you'll also be leaving yourself (and other developers) free for the non-cookie-cutter work.
It would also help if you've post-development cost factors to which you can point. There are many different forms these can take. How much does it cost to maintain the systems your clients are using, how much does it cost to add new features, how likely are clients to shift asway from your products - and therefore your company - as they grow or change, etc.
One trick I've often used is simply a special case of iterative improvement. Each time we reuse a cookie cutter, we learn more about it. We therefore improve it. Perhaps we add a feature, or make it easier to extend in a new direction, or improve the automation of cutting the cookies. The cost of this work is covered by the client, but all clients - past and future - receive the benefit of the work. That translates to your company receiving the benefit of the work.
This can actually be quite challenging. You're not just cutting cookies, but improving all of the tools used. This then takes you in the direction of better automation, etc., that I discussed above.
There's really a lot of room here for you to maneuver. But just remember to see and explain things from a business perspective. Unless you've technically savvy managers that will perform the tech->business translation themselves, you need to explain things to them in a language they understand.
Re-orient the problem (Score:4, Interesting)
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...
Maybe I'm just lucky but... (Score:1)
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.
Refactor gently (Score:1)
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.
As a manager... (Score:5, Informative)
...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.
Re:As a manager... (Score:2, Insightful)
Horse shit masquerading as horse sense - was Re:As (Score:5, Insightful)
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.
Re:Horse shit masquerading as horse sense - was Re (Score:2)
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.
Re:As a manager... (Score:2)
I'd have to fully agree with this. In this economy, a business that is making some success (and don't forget, business success is always measured at the bottom line) isn't about to go making "risky" changes.
If you are the kind of person who really believes that quality matters, my suggestion is, rather than tell that to your bosses, just look around for other possibilities. If you can find a new employer that is more in line with your thinking, then go for it. And the other possibility is to start your own business. Then you can really see if that concept flies as a business model.
Get creative (Score:5, Insightful)
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.
Re:As a manager... (Score:2, Insightful)
You're negotiating from a position of weakness. About the only thing you can do at this point in time is to start looking for another job. Only when you have another job offer, do you hold a stick more powerful than your mgr's. You can politely make some suggestions about how to do things differently, but be prepared to be blown off. If he's a good mgr, he'll listen and make changes. If he's not, well, that's about all you could do. At no time should you risk a direct head-on confrontation, without having something to back you up with (like a job offer).
Use this as a point to decide on what you really want to do, and where you really want to go. Doesn't sound like your current company is where you want to be at, so decide on what you want. Then start looking around for something that's closer to where you want to get to, try to get a job offer, turn in your two weeks' and leave. Be patient, be persisitent. Persistence will trump just about any other virtue.
If you want to do something completely different, now would be a good time to get training.
Re:As a manager... (Score:2)
This implies that you (an employee) are indespensible and that the manager is a dumb-ass. While the employee's heart is in the right place, it doesn't mean that they indespensible. All to often, I've seen thoughtful employees with skills barely above that of a trained lab-monkey try this play. Guess, what? They find themselves out of one job and trying to keep the next after the next major layoff.
This also does not imply that managers are omnicient, either. There truly are Dilbert-style managers out there. But, most have a greater grasp of the company's objectives or upper managements perspectives and corporate climate than the grunt employee. Many know that tinkering with profit in a unprofitable way is a sure path to unemployment and are cautious about taking the route. And, most won't fire you in direct response to making a suggestion or providing them with facts (see above paragraph regarding layoffs).
Best course of action is to learn your boss's motivations and appeal to them. Do some research and show them hard facts. Give them links to information they can use. And then, let them run with the ball if they so choose. In the meantime, if you can make improvements in the quality of your product without upsetting the balance, then do so.
And, by all means, if you truly have a Dilbert-style manager, read a few copies of PC Magazine (or similar) so you can see, first hand, what technical dribble they are assimilating. Just be careful not to believe all that you read.
Remember, "Know thy enemy" and "to thy own self be true" and learn to manage your manager are the keys to success.
Re:As a manager... (Score:2)
The Master said, "The mechanic, who wishes to do his work well, must first sharpen his tools. When you are living in any state, take service with the most worthy among its great officers, and make friends of the most virtuous among its scholars." [mit.edu]
Re:As a manager... (Score:2, Insightful)
I have to object to the (probably mainly Americentric) notion of a quality workspace, yes I do define two-way communication in my workplace as a "quality" parameter, to be a pure factor of the economic tides.
You are saying that during labour shortage, labour rules and during labour surplus, management rules. While I can see that it will impact it somewhat, (salary mostly, not strategic influence) it most definatly is not the one and only factor.
How about coutry/company culture, governement and plain bussiness tactics? To me it seems just as silly to let your company be run by screaming labour monkeys when there is some shortage, as it is to let it run blindly by management without labour input.
How about changing the world for the better? How about just trying to communicate BOTH WAYS first? "I hold the hammer, so I will hit your head today" is really not a good relationship.
IMHO working for a US (culture) company, compared to working for a Dutch (culture) company is/was very different in the 80's, 90's, and 00's it still is.
A whole lot different then the difference between shortage/surplus in my job-market.
Gr
Are you nuts? (Score:4, Informative)
That said, I think a better way to look at this is
a) ignore the money aspect (both yours and your employers) Always trust that a business will do the thing that makes it the most money. You won't change this in the near term. If the money is that important to you, you should either stick it out or try to find a job that pays similarly doing something you *enjoy*
b) If you aren't happy doing what you are doing, look for guides on the web that give professional suggestions about how to bring it up, what to do and not do, etc. with your boss. do NOT just give an ultimatum, especially not in public company
c) If in the end, after rationally sitting down with your boss and explaining your position in a professional manner, you still aren't happy with the work, and your changes don't make business sense for them (even if you still know you are right -- you can lead a horse to water and all that) maybe you should consider leaving! It doesn't do much good to be in a job you don't enjoy.
Re:Are you nuts? (Score:2, Insightful)
To sum it up - make your point. The worst that they can do is say no and, at the end of the day, it is their choice to make.
Re:Are you nuts? (Score:2)
Maybe you've worked in bad situations, but this is completely untrue in a good company. Any reasonable manager (insert snide question about the compatiblity of management and reason) knows that the people under him are intelligent (if they are) and have a perspective that he does not, so they will often see things that he has missed. If you took a poll, I'm sure that most managers would wish for workers to participate more in leadership.
Always trust that a business will do the thing that makes it the most money.
Fundamentally ludicrous: this would imply that companies don't make mistakes. But a cursory examination of companies, or experience at any company, shows that companies screw up with regularity. It's sometimes even clear to observers outside of management that a company is screwing up. Companies should be grateful for any input from employees that will allow them to screw up less often.
well there's a first (Score:1)
Charles de Gaulle said: (Score:1)
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.
Re:Charles de Gaulle said: (Score:2)
And another job is probably not going to be waiting for very long. Any business that has enough work to need to hire another person is probably very concerned about making deliverables to their customers (or else they would just have the existing staff do it and save money on salaries). Given they probably got 500 resumes for the job, and interviewed 20 excellent candidates of which they might well like to hire the best 5 to 10 if they had the open slots, if you get the offer, you better take it right then or risk losing it to #2 who is probably just as good as you are anyway. Then you can decide if it is worth explaining it to your old boss during the exit interview (if you even bother with one).
Software Reuse == Quality? (Score:1)
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...
Software Reuse == One Size Fits All (Score:2)
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.
Make the best possible reusable functions (Score:3, Insightful)
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.
Make them on your own time ... on SF (Score:3, Insightful)
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.
web sites that suck (Score:1, Troll)
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!".
Not a real good idea (Score:1)
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.
Don't give management the power (Score:2)
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 [slashdot.org], 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).
Downfall of IT (Score:1)
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.
This is the way the world works.... (Score:2, Interesting)
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".
Re:This is the way the world works.... (Score:3, Insightful)
This is one of the reasons I refuse to do work as a developer in most cases. My professional work is systems and network administration, although my 2 decades of programming does (except in the last few months) get me plenty of calls to come interview for some programming job. Right now I have enough cash and contract work to hang on for the next 2 to 3 years, so I'm working on developing something for my own business idea. Interestingly, while I thought I'd have plenty of time to do it right, I even feel my own pressure to get it done and get it to market sooner. That is a fact of life. The concept of getting things to market sooner really is valid from a business perspective, despite how much the geek in me says that's crap. At least during the economic downturn, it's less likely that competitors are doing as much that will compete against me, so I can take a little time to get this done right.
Bad idea (Score:1, Interesting)
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 ...
Re:Bad idea (Score:3, Insightful)
Quality is the responsibility of everyone. Do you think you can write whatever and however you want and expect the QA department to magically instill quality into the product?
QA assure quality, they don't create it.
working w/ management (Score:1)
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.
Re:working w/ management (Score:2)
Management will not start out asking for the perfect system, they have deadlines. However, they also don't want a bunch of crap that will cause them to lose customers.
That's where the refactoring is important. It's rare to be able to throw everything out and start over But every update can be an opportunity to improve the system. And over time, that means more reliable technology, and less programming labor costs, which management pays attention to.
What problem? (Score:1)
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
This leads me to a similar question... (Score:1)
Management commitment (Score:1)
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.
Just out of college? (Score:2, Insightful)
Only the customer can do it (Score:3, Informative)
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.
Make quality your special niche, not features. (Score:3, Interesting)
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 [leica-camera.com] 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.
Suggest chargeable services (Score:2)
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.
Management Conflict of Interest (Score:2)
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 [wired.com]").
However, there is a more insidious dimension to mismanagement of software engineering projects that is one conceptual step beyond "The Mythical Man Month [amazon.com]":
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.
Discuss, don't Threaten (Score:2, Insightful)
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?"
XP, baby. (Score:3, Informative)
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.
Quality. (Score:2)
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.
Quality Programs cut first in hard times... (Score:3, Interesting)
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.
--
Welcome to the REAL WORLD (Score:2, Interesting)
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.
Quality is Free (Score:2)
It's all up to the customer (Score:2)
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.
Finding the right clients is the real key (Score:4, Insightful)
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 [amazon.com]" 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.
Find a job where quality is important (Score:2)
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.
Why do you care? (Score:2)
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.
My Experience (Score:3, Interesting)
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.
Welcome to the real world... (Score:2, Insightful)
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...
Be careful what you wish for (Score:5, Insightful)
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.
Two ways (Score:2)
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!
Re:Two ways (Score:2, Informative)
1. Identify the problem(s).
2. Collect data to support your claims, use forms, i.e. number of unitialized variables in code X on date mmddyy, etc.
3. Write your report, preferably in the form of charts. Don't forget to keep copies for yourself.
4. Submit your reports to management, 2 separate managers to create accountability.
5. for(;;)
congratulations, you are now the first member of the quality assurance team.
This way you will have an impact on the other programers. Oh yea, one last thing
Kevin Myers
aka
Warp1
Tracer Bullet
Spaceman Spiff
JW Black
And any body else I want to be.
Go Between the Horns (Score:5, Insightful)
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
"Quality" is not an absolute (Score:2, Insightful)
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" first! (Score:3, Insightful)
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 [geraldmweinberg.com] 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.
Re:Define "quality" first! (Score:2)
A project for an embedded system using C++. (Why they chose C++ for embeded systems, I'll never know...anyway) Developer A is a long time C++ advocate, while Developer B is an C programmer of embedded processes that has been dragged kicking and screaming into the project.
The design calls for one class to collect alarms from the hardware, and another class to massage the data and pass the results to a higher level.
A implements a design that calls for the Massage class to call a callback function in the Collector which sends itself a system level message which calls several functions which eventually sends a message back to the Massage class with the address of the alarm block. All the message passing and function calling was implemented to support the C++ concept of data hiding. Damn good quality, but very heavy code that has to be executed for hundreds of objects twice every second.
Developer B looks at the abstraction of the implementation and says, "What the f%$#?!" He changes the code to make the alarm block public, and then the Massage class will simply look directly at the alarm block. Breaks the hell out of C++ methodology, but it's a pointer lookup versus a stack of message passing and function calls.
Who is the better developer?
I submit that if a thread discussing such a situation runs more than 4 serious messages then it would be foolish to give your manager the 'my way or the highway' speech. If he went 'your way' then he would get the same speech from another developer with a 'different way', and since he doesn't really give a shit (as long as something works) then it'd be the highway for you.
Ever heard of design? (Score:3, Insightful)
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.
Well... (Score:2, Insightful)
Suggested reading, Parnas' "How to fake it" (Score:3, Informative)
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. [aw.com]
What we do... (Score:2)
They need a code monkey, not a programmer (Score:2)
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.
Re:They need a code monkey, not a programmer (Score:2)
I really don't know what the deal is with this slashdot attitude that "work = self-respect". That's total hogwash. Self-respect comes from yourself, and work is an EXTERNAL part of your life. Letting work anywhere CLOSE to your self-respect means that you don't have any.
Work should be a challenge. If its a challenge, keep on going. That will make you feel great at the end of the day. But nothing about a challenge was mentioned in the post; only quality. If you don't have time to do your own QA, then you're probably already being challenged, even if its only "code monkey" work.
If I were in your shoes, I'd start looking for another job as a Software Engineer, but wouldn't even THINK about leaving your present job until you've got another offer... the current job market is INCREDIBLY thin right now, even for programmers (compared to what it was a year ago).
Re:They need a code monkey, not a programmer (Score:2)
Re:They need a code monkey, not a programmer (Score:2)
Use the right language (Score:4, Insightful)
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.
Quality vs. Boredom ? (Score:2)
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
Develop a product centre (Score:3, Insightful)
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.
Might be too late for you... (Score:2)
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.
Forget it (Score:2)
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.
Re:Just do it. (Score:2)
Re:The customer doesn't CARE (Score:3, Insightful)
The point was to emphasize that when a pizza is delivered to my house, I don't care if it was cooked in a Vulcan or Middlebe-Marby oven, if they used X or Y management style or if they were driven by this factor or not.
All I care about is that if the local manufacturer of circular pseudo-Italian cuisine:
delivered it fast enough;
delivered it as specified;
wasn't stuck to the top of the box;
didn't taste like the top of the box.
... yet amazingly enough, even in those cases, I didn't give a fig about how the restaurant was managed.
I mean if I wanted "quality" Italian, then I'd get dressed up, take the wife downtown, spend some time and some bucks
Re:A manager's perspective... (Score:2)
First, remember that business is about profits.
Business in most of software companies is almost never about profits -- it's about vanity, power, politics, be it at the worldwide level or between lowly paper-pushers with MBA, pet projects, ass-kissing, blatant fraud, VCs' money-pumping machines, etc. At best it's about looking good in the eyes of few "important customers", in which case someone might influence company through them, but that still requires a lot of political bullshit, that programmers usually aren't capable of.
Re:Look at Mozilla vs MSIE (Score:2)