Slashdot Mirror
Ask Slashdot: How To Convince a Team To Write Good Code?
An anonymous reader writes "I am part of engineering team that maintains a very important component in our company. Our code quality and general engineering quality focus has been very weak: we have frequent buggy releases, our latencies are shooting up, our test coverage is nearly non-existent, and it is impossible for a newcomer in our team to get up to speed and be productive in less than a month due to unnecessary complexity. A group of 2-3 of us want to change that, and we know what needs to change technically — the better code review and release processes, better build tools, etc. But despite that, the quality of our code and design continues to suffer, and poor code continues to get released in the name of keeping the scheduled release date (product guys don't like to wait). We feel that if the right thing is done every time, we would can eliminate our issues and still release at the same pace. How do we effect the social change necessary to convince them of what is better and encourage them to take the effort to do it?"
Do you work for Blizzard?
1. Higher Pay
2. Good Management
3. Beatings
Pick any two.
"We don't need more people; we need better people!"
Strippers and blackjack
Make good code or no rice.
And perhaps his boss as well.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
What you have just described is what happens when Management does not see value in what you do.
To them, you are just an interchangeable cog. Like, the brand of air conditioner in the office. Or the janitor. It has no bearing on their success and they don't really care what you think about anything.
The way they see it, if you don't do your job, they'll just replace you with something else.
Your best bet is to leave. And do as little work as possible in the meantime.
It is very clear that your company is a typical feature and marketing driven morass. What happens is you flog yourselfs until something goes horribly wrong, a bunch of people are fired. Then there is a new director of technology, who gets a ground up rewrite approved to enter some new space, and the cycle of accretion and feature creep starts all over again. So advice? Polish your resume or make good friends with who ever will run the purge when it happens.
Fugue for Aaron Swartz
Kick them in the nuts. Now that you have their attention tell them to write good code.
Your inability to proof-read the text of your submission does not give me hope for your team. ("I am part of engineering team...", "...non-existant...", "...we would can eliminate...")
Of how much time and productivity is being wasted on inadequate practices and how much you'll improve your product, discover bugs faster and generally innovate with your improvements. Worst case, you'll need to do a shame trip on a few egregious offenders (pick their work and try to exclude names) and show how you'd do things differently.
The benefit from your improvements must be obvious, immediate and beyond reproach.
Fair warning: You cannot change the mind of management if they're more worried about maintaining the status quo. A very likely issue, if it's been this long with no improvements. All of the above will only work if your 2-3 people have any position of authority within the company. In my experience, the old-dogs don't want to or can't change, in which case you'll be on your own.
Of course, you will also earn the ire of those around you if it's that type of atmosphere. People fear change when they're not the ones doing the changing.
If computers were people, I'd be a misanthrope.
to outsource your work to someone in India giving you time to peruse Reddit?
You will never convince your team to write better code if you cannot review thier code and throw it back in their face.
Also your QA person should be slapping thier dick in the dirt.
Do you maintain your own code? If it's as bad as you say it is, it shouldn't take much to convince everyone to improve the quality. Otherwise, try to start small. See if there's a really tiny project where you can try to implement some good practices. Make sure you document your process, and record some basic metrics (e.g. time spend developing, defect density, time spent fixing said defects, . Once you've done that, compare it to some of the other projects that have been done. If the results are good, you'll have a lot easier time selling it to management and to the rest of the team. And don't expect things to change overnight either. Successfully implementing change is a process unto itself and something that can take a while to do correctly.
Hopefully you have a QA team...if your project is large enough and you do not have a QA team, consider proposing the concept to management. Proper controls and planning on unit test, functional test, system test, solutions test, things like that are all really required to help keep large, multi-developer projects in check, especially in this day and age of migrant coders, on-and-off contractors, and out-sourced-then-imported coding jobs.
Having strict thresholds as to allowable defects per release, enforced feature regression guidelines, expected/projected pass/fail rates per test case, etc. can all be very useful if used PROPERLY to improve code quality. I highlight properly because some managers misuse metrics as the final yardstick of worth of employees, when at the end of the day it is much more complex than developer a fixed X defects or tester Y passed Z test cases this week. Implement proper code reviews, have a consistent and formal process for testing, finding defects, defect resolution, targeted releases. Have your QA devise up with your strategies, test plans, test cases, have them cross-reviewed, and start testing cycles based on release cycles.
If you aren't doing any of the above, imposing some of what I mentioned is sure to have a positive impact on subsequent quality. If your code sucks, it will reflect your team, your company, your management, and your bottom line in the long haul (IMHO, YMMV, IANAManager).
Signed,
Your Friendly Neighborhood QA Tester
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
two times before.
People do amazing things when they feel like the thing they're creating is an extension of themselves. Far more than any engineering process or philosophy I've seen, the best work I've seen in my career is from people who identify strongly with their work.
"Why can't everyone just be straight with me?"
"Because we live in a bendy world, dear."
Figure out who stands to gain, and convince them. For management, try two tactics in the sales pitch: 1. Better customer experience (seeing fewer defects) due to higher quality code. 2. Faster and more predictable creation of new features due to higher quality code (after the investment in the needed changes) which should improve business results over time. If these fall on deaf ears, then play hardball and say that without some investment in the code base the code will become unable to support the business, and the business will not be able to continue. It takes a while to get here, but it does happen. In parallel, sell these changes to the development team so that they welcome instead of resist the changes. Make sure the dev team is part of deciding and implementing these changes. I expect that most developers would welcome the changes you suggest. If not, perhaps they would fit better in a different environment that required less disciplined software engineering practices.
Get your team to write "Good Code", eh?
Does your team write bad code? Do they think that their code is bad?
Why do you think that your team writes bad code?
I'll bet a nickle that the problem isn't your team. I'll bet that you're the type to write a factory factory factory under the banner of "flexibility" and not understand why everyone groans at your "superior" code.
Required reading for internet skeptics
Yes a LOT more QA is needed also out side the box testing needs to be done do not just have auto tests they are easy to code to pass them while failing big time.
Get management buy in, and have them pad your estimates to allow a little bit of code rework in each release cycle.
If that fails, lie about your estimates and use the extra time to rework the code in each release cycle.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
Show them this lousy website and tell them that is what happens when your company propagates lousy code - your existence goes to pot and your company is sold for very little money to a larger company who also doesn't care.
That should scare them straight.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
the goal is to remove as much money as possible as soon as possible from customer's pockets and to put it in the pockets of your senior executives and stock holders. now shut the fuck up, quit jacking off on company time whining on slashdot, and get that shit shoveled out the door!
Look for another job and be vocal about it. This is one of those cases where you have to be selfish and look after your own interests. Get your co-workers to do it too.
There are three possible outcomes and they all have upside for you.
1. They pay attention and fix things
2. You leave and get a better job
3. They fire your ass and you get a better job
Clearly your present position is not advancing your career. Your future as a developer is mired in the same muck as your code.
Dude most stupidest question ever...
Embed your culture in a fresh structure. Your core team will have high ideals. Your new hires will be ambitious. Overvisioning will force you to cut corners to keep your first contracts and meet milestones so that everyone has a job. You will move forward with the intention of a version rewrite that addresses the hacks. New hires will question the legacy BS, Rinse, Cycle, repeat.
(1) Code reviews. At first, just get 'em to grab a passer by to look at their code prior to check-in. If the PB cannot understand what they've done, they haven't finished the job. Later on you can upgrade to more stringent reviews, but the first thing is to get *some* reviews happening *at all*.
(2) Comments and (some) documentation. You need to lead by example. This stuff isn't optional.
(3) Unit testing. If your code base is a pig, you'll need to start somewhere and begin teasing out the "bits that think" (easier to UT) from the "bits that talk to things" (these are harder to UT and you can get away with integration testing here until you're in better shape). Unit testing is a skill anyone can learn. Sack 'em if they refuse to do it!
(4) Simplify your processes and your architecture where possible. Avoid trendy bandwagons. If the obvious thing works and is maintainable, then that is probably the best way to go.
You sound like a smart person who wants to be surrounded by great colleagues. There is a tremendous shortage of computer science talent nationwide. You don't have to work for a company that 'does not get it'.
I've had great success acting on my own initiative and begging forgiveness afterwards.
That being said, the bottom line is I was able to show marked improvement. If your tools and processes have no tangible benefit - then I'm sorry, but you're going to have to pay the price for your insolence.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Buy everyone a copy of the book "Code Complete". Give them a few days to read it, then have everyone agree to follow its guidelines. Done!
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?ie=UTF8&qid=1358912261&sr=8-1&keywords=code+complete
ask your question here...
extremeprogramming@yahoogroups.com
and here...
scrumdevelopment@yahoogroups.com
captcha: moulding
1. Write the worst code you possibly can.
- Unnecessary subclassing and then reference methods or functions from two or three or four subclasses away.
- Use variable names that don't reflect the values that hold them
- Use as many classes as possible
- Make the code as fragile as possible, use threading if possible avoiding mutexes
- Make a lot of files that do very small things
- Put large blocks of untested code that only run once a day.
- Implement large data structures two different ways and then write fragile translation code to transform one object to another
- Create an api that requires it's own processing loop completely incompatible with other processing loops.
- Declare the current language insufficient for your task and rewrite everything in lisp.
2. Leave and start a new company
Ok.. those are strong words in the subject, but inducing a culture change quickly is something you can incentivize. I'm not sure of your particular situation, but here's two ideas:
1. Bribe them. Companies usually call this merit based bonuses. Break the goals of the team(s) into individual goals. If a particular module is due to be rewritten for the next release, then pay a bonus if it gets done correctly and on time. If it's not done correctly, don't pay the bonus. If it's not on time, don't pay the bonus. With regards to it being "correct", that falls into the next item..
2. Punishment. If the code sucks, don't commit it. Force the programmer to rewrite it. That even might mean rearchitect it if there was architecture involved. Programmers hate repetition. They will very quickly learn that if they are forced to do something over that they can do it better the first time. If they find themselves working late hours to meet a deadline, perhaps because a bonus is riding on it, they'll get better.
Most important, make sure your deadlines and features are realistic. Are you sure they are? Are people being sloppy because they feel too pressured? Shipping a buggy feature isn't a feature.
----- obSig
and we know what needs to change technically
Which we?
Is the technical team than need to be convinced? Either you convince the guys to do the right thing (write better code as part of professional pride) or you need to convince the managers to impose doing the things right (i.e. better processes, tools, infrastructure). Did you note the difference between doing the right thing (part of the leadership) and doing the things right (part of management)?
If it is the management team that need to be convinced, then either:
a. the cost of lack of quality is greater than the cost of "missed opportunity" (i.e. the cost of not releasing in time). In this case, management should be on your side and be ready to accept an extra investment in setting up the quality system; or
b. the cost of lost opportunity overshadows the cost of non-quality - in which case your focus on quality may not be the right thing (for the business) and you should consider your position: accept the risk of non-quality and forge ahead to early releases (maybe you'll get enough time to fix the bugs) or not accept it and find for yourself another employer.
Questions raise, answers kill. Raise questions to stay alive.
Hopefully you have a QA team...if your project is large enough and you do not have a QA team, consider proposing the concept to management. Proper controls and planning on unit test, functional test, system test, solutions test, things like that are all really required to help keep large, multi-developer projects in check, especially in this day and age of migrant coders, on-and-off contractors, and out-sourced-then-imported coding jobs.
My wife works in QA, and simply having a QA team is not adequate. Yes, it is one more check (or balance), but it's also redundancy that can quickly overwhelm the primary focus of your coding team.
You need strong leaders in your coding group. If you have strong coders, and they're not strong leaders, think about structuring the work in a way that forces the code into spec. Find ways to develop those leadership attributes, and train the other coders to conform. The nice thing about working with coders is that a structured training program (training, as in behaviouralism) will work - routines, structure and cause/effect (or compulsion loops) are much easier to implement with an emotionally detached, logical group of individuals. You can actually discuss the "training" routine (but don't label it as such) and expect a level of rational resistance to change. Rationality can can be worked with, and in my experience, you don't get people who are much more rational than coders.
It doesn't have to be a permanent arrangement, and it doesn't have to involve raises. It does have to give your team an opportunity to make the transition to a new way of coding without feeling threatened. Think of it as a clean break from a bad relationship. You can't stay friends, you need a complete change of scenery.
- Nec Impar Pluribus, or so I'm told.
Don't rock the boat.
Although pride of workmanship improves profit it's viewed as a counter to the current direction of the wind. This is a matter for which management will ultimately be blamed. However, as producers you should learn to understand the source of the flawed code beyond time constraints.
"Management creates quality", W Edwards Deming
"Our code quality and general engineering quality focus has been very weak"
So you want people to write good code on top of crappy code. This is hard for people to do. Just as it would be in any field to fix up crappy work. A carpenter, plumber, artist... will all be demotivate worked on a botched job.
"and it is impossible for a newcomer in our team to get up to speed and be productive in less than a month due to unnecessary complexity"
How many newcomers are joining your team that this a problem? Lots of churn in your staff is going to be a detriment to performance. No different than any team based sport.
Before you worry about details like code reviews... you must get the picture right. Do you value software developers as a skilled profession to train them on the code base, keep members on the team for their knowledge...
Better still, are you hiring good people? You can't convince me to be a good artist. I can't draw for the life of me.
After that, focus on quality in new code and components. Provide some time for rewrites of code they really hate.
That ought to work.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
In programming, there's a lever... In one side you have: more time writing, in the other side you have: more time reading.
Code is written once, but read many, many fucking times.
If you ignore the importance of readable code, think in the following scenario: your product finally went live, and there's a bug. There is no fucking time to fix it. In that moment, you would like to look under the hood and see something that makes sense. Bad code will be hard to read, you will maintain it, and possibly introduce another bug, then another fix is issued, but another bug is introduced, and so on.
Write decent code. Challenge duct tape programmers, they poison your project and the industry.
Yep. You're going to have to make a business case for what you want to do and show management what it will save in $$$ or change will come with much more pain, if at all. You are going to have to argue sensibly and make sense to them in a language that they understand. This should be at most two to three pages covering the nature of the problem, how it can be solved and a budget and/or cost comparison. You want to be coherent and concise without getting into too much detail and three pages is about as much as you can ask a high-level manager to read. You are talking about major process change within the structure of the company. You might think it's trivial (or not), but understanding as much as you can about what effect this has across the board (not just in the software you're writing) will help you make a better case for this kind of change. You will also need to appeal to the bottom line.
What you are describing is a work place that does not follow modern software engineering practices. Management does not see the value in it. It will not devote the resources to cleaning up the code or refactoring. It will not develop training for new employees.
Of course, two or three of you want to change it. I think "you" are two young people who don't understand that management doesn't care you have an older friend who agrees it could be better (although he understands nothing will change).
I think it's pretty hopeless but it might be worthwhile to make some effort. You and your friends can put together a pitch to management. Emphasize that what you are suggesting is the orthodox way of developing software these days. Try to keep the things you want simple and practical. You might want to show management this Slashdot article so they can understand the perspective of the software engineering community on this issue. But don't come across too angry and or too radical in your suggestions. Be agreeable, and watch for changes with a cynical eye. Remember management might say they agree with you, but talk is cheap.
Other than that, I think you need to serve your time where you are at, and then leave for some place better. Listen to lots of podcasts and read lots of articles. Keep abreast with the latest technologies and practices. This will help when it is time to leave.
You will eventually learn that you can't fix management. You are not in the position to fix everything about your place of work.
Democracy Now! - your daily, uncensored, corporate-free
Date-driven development is almost always a disaster. The only way it works is to completely finish a reduced feature version of the application, add and test one feature at a time to it, and ship what you have when the date is hit.
TDD forces good test coverage, and reduces or eliminates regression errors.
Also, TDD is correlated with successful, robust software, but code review generally is not. (Unless you count QA as "review".)
Yes a LOT more QA is needed also out side the box testing needs to be done do not just have auto tests they are easy to code to pass them while failing big time.
You also need a management that is willing to stand behind the QA team. QA can be a thankless job and when you start trying to teach new tricks to a bunch of old dogs who have gotten away with sloppy work for years it can lead discontent in the ranks. When the QA team starts doing things like limit developer's freedom to do projects in any language they happen to have the hots for at the moment, implement a code syntax checker to enforce coding standards, mandate a set of standard coding tools, make devs write unit tests, make user tests mandatory, throws code back at devs because it failed testing, .... (the list goes on) developers get pissed off and sometimes management folds. You will not change anything until you declare that untested and unreviewed equals unfinished if you really want to piss the developers off you can add the caveat that undocumented also equals unfinished. Just remember that the best way to boil a developer is by turning the QA heat up slowly. Don't make too many changes at once. Another thing about QA is that alluvasudden (according to CS studies) your developers are spending 5+ hours writing unit tests etc. for every 10 hours they spend writing code and that is not always popular with other people within the company who have grown used to them pumping out a lot of code with quality being a fortuitous byproduct of making deadlines.
Only to idiots, are orders laws.
-- Henning von Tresckow
There is too much backlog of work, and despite bringing in new people for the express purpose of improving project management, not much is changing. Our team lead is (understandably) not very enthused about suggestions to improve things, since he is up to his ears in client requests and complaints, and all of us spend all our time barely making our deadlines using the cobbled-together framework we're used to.
It seems like a self-perpetuating problem... every time we talk about fixing things, it's always "after we catch up on our current projects."
Infrastructure, tools, culture.
Infrastructure: continuous build server, that runs unit tests, continuous deployment to staging servers (and eventually live), github, github enterprise (or equivalent)
Tools: depending on what language you are working with - there are many great tools to monitor code quality. Good example would be resharper for c#.
Culture: Get everyone to do pull requests to main repo. No direct committing. Also no merging your own pull requests. Someone else has to do it and while doing it review it. Only give commit access to main repo to trusted people. Give them ability to give commit access to people they trust too. Call people on bullshit code.
http://dilbert.com/strips/comic/2012-08-20/
The environment I'm working is a semi-military establishment with its top-level management ex-military former mainframers. And the situation there is that they have gone from having virtually no QC process in place to a water-fall model that allows the top managers to micro-manage the software development lifecycle at almost all stages, which they do.
Here are some further characteristics contributing to this malaise:
- Weak technical leadership, mid-level managers either have a very-out-of-date IT skill-set or do not have an IT background at all. This means that management is at a disadvantage when weighing technical solutions up front and going forward. This also usually leaves major technical decisions to the discretion of junior staff, who may not be sufficiently conversant with the technology they advocate (for example, recommend one solution that works fine for a small web-server with moderate traffic but does not at all scale up to large traffic environments), and this causes projects to fail.
- Lack of credibility with business section. Due to problems created by the previous reason, the business section, lacking faith in their IT deparment, then is tempted to (and in the place I am working actually does) dicate technology decisions to the IT department. The see some expensive tool or platform and then dictate to IT that they have to use it. IT having no choice in the matter purchases said snazzy tool/platform, runs into big problems cost overruns, and then gets further blamed for incompetency. A senior VP in the technology department was forced to retire because of a decision imposed on him by business that ran into cost overruns.
- Lack of incentive for developing skills in-house. The establishment I am at is using more and more commercial J2EE solutions, but they are unwilling to either train their current development teams in Java or hire people with J2EE experience. Even mid-level managers are complaining about this. In their words, top-management thinks if it can't be done on a mainframe, then it can't be done.
- The preceding points to a BLUE COLLAR CULTURE in the IT department fostered by management at top- and mid-levels. What is "blue collar" about the IT culture is that it is expected that little or no innovation is expected to take place in the course of developing solutions - even in new product development. Research and development is generally frowned upon as unnecessary.
- And when the blue-collar IT culture runs into reality, expensive contractors or contracting firms become a necessity, because you lack the inside technical expertise to implement new technologies. Hardware and software becomes obsolute and unsupported, and especially if a whole line of software or hardware becomes end-of-lifed, you had better be prepared to port your legacy apps to some new platform. New customers with lots of money and influence also have their own demands, which a stagnant IT department is ill prepared to accommodate.
And so the vicious cycle continues.
The problem is fundamentally one of who is in charge, and a distant second is who you hire. But mainly it is who is in charge, because they are the ones who hire or fire.
If the problem is fundamentally about who runs the show (and they have to have clout with other influential down-stream customers, like the business section or customers or board members), then start with your CIO or even your CEO. Yes, they will make most of the difference. They can start giving underperforming or toxic mid- and top-level managers "golden handshakes" and replace them with more competent people. Incentives can be put in place to improve staff. Hire better developers (if you are weak technically and are a manager, then hiring good people is more a function of luck than anything). And so forth.
So, the answer to your question (what can be done to change the culture) is very little. You can't do much at all from the bottom. Even if you are a mid-level manager there is not much you can do to change things. I've had the
The truth is - unless people realize it for themselves - it's really hard to do. Not every programmer has pride in their code and a genuine desire to learn and improve. Let's say you get approval to rewrite the code and reduce the unnecessary complexity. Most likely, the code will break and you won't know till it's too late. This is because, no matter how convoluted the logic - it would still be relatively debugged code. Rewriting stuff will break things, and without the unit tests - it's really hard to even get a clue where. As a result - people will blame the rewrite for the new bugs - and still never get the point.
My suggestion is, start with pushing for process and get tests written for existing code. Try to convince people that the reasons for your release problems are the absence of good process and good tests. Explain that tests are a way to automate the drudgery of manual testing and will save time - so that it is comprehensible to management. Once those two are in place - you can safely rewrite the code without breaking existing functionality - thus avoiding being blamed for your "meddling". You can then start pushing for code refactoring next. Eventually - it will be possible to display the tangible benefits of a well-structured code based. It'll be a long hard slog.
Sometimes though - the people around you are too calcified in their thinking to want to learn or to do things "better". In that case, find another job.
It's not just about writing better code. You also need to ensure that you have enough time to do a proper job. Sounds to me like you could do with sorting out your estimation process. If you're running out of time to do a decent job, give yourself more time, or de-scope the delivery. When you get code & test estimates, are you taking into account the fact that your code sucks, so you need to add more time for the rework that is bound to occur?
A product manager who will never de-scope functionality or move the date for the sake of quality has no pride in his work, and I'd strongly advise against working in a company where such people rule the roost.
Just based on what you seem to be saying, it sounds like there are a number of issues. These issues are probably more social than they are technical. It also sounds like the team has little incentive to do the right thing, and that you more than likely have a clueless project manager (probably, but not necessarily a woman) who refuses to understand the technical aspects of whatever it is you're doing.
If the problem is poor management, you're going to need a better project manager. Someone with a history of delivering results in situations like this. Unfortunately, great project managers are so few and far between, that I can say with some certainty that it'll take you at least a year, possibly longer to find the right one.
If you're certain the issue is not the project management, take a look at the processes, and limit who has commit rights on the main cvs/subversion/git branch. In fact, you actually want to go so far as to give the keys to the main branch to one person who will be held accountable for the quality of the overall system. This way, nobody feels left out or punished. And everybody feels bad for the guy who can be fired for your fuck up... at least, until he starts pushing back on bad code.
Require all code to go through an approval and review process by this person before it can be committed to the main branch of your source repository. If necessary, tie this person into the quality assurance apparatus that you already have in place for your product. Sell it to this person as a "promotion," and pay him a couple grand more a year to do it. It's not going to kill the company, and it should be enough for this guy to take the job seriously.
Throw the word specialist, or manager in his title, and give him the the power to send code back when it needs to be fixed. Make no mistake... feelings of empathy for his plight won't last long, and he will be hated if he's part of Q/A, unless he's exceptionally charming. But do not flinch on him being the one and only person allowed to commit to main, come hell or high water. There will be objections, and they will most likely come from your worst offenders.
I know it sounds harsh. It's just that there aren't a lot of ways to fix a situation like this one. In my experience, this method is the least invasive of the options you have available, but it can be quickly derailed by bad or inappropriate project management or team governance. Be careful, see it through, and you'll be fine.
This signature has Super Cow Powers
until morale and performance improves
How do we effect the social change necessary to convince them of what is better and encourage them to take the effort to do it?"
Make small incremental changes If you try to make all the changes at once, you have a high probability of failure; both at the implementation level, and at the 'convincing management' level. Choose a small change that has a high probability of success, for example, set up Hudson to do automated builds. When people see benefit from that, they will be more likely to make other changes. One thing at a time. But:
we have frequent buggy releases,
This raises a warning flag. Are you adding bugs to the product that get released? If so, you are the problem. First figure out how to write high-quality code yourself. That is your first step, even if you're working on a messy code base that isn't an excuse to make things worse. Don't even think of telling your team what to do if you can't write stable code yourself.
"First they came for the slanderers and i said nothing."
I'll bet that you're the type to write a factory factory factory under the banner of "flexibility" and not understand why everyone groans at your "superior" code.
That is so 2008! These days we've shown that an abstract singleton factory method bridge prototype facade is the only way to go for maximum flexibility! Get with 2013! :-)
Now if you'll excuse me I have to go write my unit tests for the old factory factory singleton - see how the old way makes it difficult to test!
Have you tried making sure they have access to great food and drinks?
One of you has to take one for the team and become director of engineering.
My team has an hour meeting every week where we review code, how it could be better, what we can do better next time, how our overall system could change and improve. Instead of ragging on people, we sympathize when they are under deadlines and stress. People were hesitant and embarrased at first, but over time, as we've nurtured a supportive envrionment, people feel free to air their problems and ask for help. Knowing that your teammates truly have your back makes you feel good about yourself want to succeed. Sometimes people will give presentations of design patterns, functional programming, certain libraries, or new technologies like REST. Nothing big and fancy, just enough for everyone to get a handle on it and small enough to digest mentally. I don't know if this can work on every team because IT people seem to have a pandemic negativity and perfectionist syndrome. In the long run this just makes you give up and write crappy code, when you believe everything is futile and worthless when it's not perfect.
Computers are useless. They can only give you answers.
-- Pablo Picasso
Why is social change the preferred method to convince anyone that your way is better? You will probably have more luck with facts and well formed arguments in favor of your approach.
Start showing how much faster you can get work done by building and maintaining your own test suite. Once they start to like the idea, they will ask that it becomes a fully automated system with full team focus. You won't need to convince them.
That is the main thing but the aforementioned "sense of ownership" is a great idea, too.
You have the wrong focus. Expending your energy to "How do we effect the social change necessary to convince them of what is better and encourage them to take the effort to do it?" will get you nowhere. If you want to improve the code, it is not the programming team you need to convince. You already state that code suffers to meat the deadlines.
If you want code to improve, you need to convince management of the value of the improved code, so that it becomes their priority. Until they value it, the deadlines won't change and the code will continue to suffer.
You don't work for Oracle do you.
You say you have software changes with a lot of bugs, bad design and slow implementation. All these are signs that you have bad programmers. No amount of culture fixing and procedures can fix that problem. Identify your good programmers and make them do all the programming (If you have no good programmers , you will have to hire some). To the others assign support roles or let them surf the Internet all day if you cannot fire them. It is not that difficult to identify the good ones. They are the ones whose changes go in with few or no problems.
First prize is a Cadillac Eldorado
Second prize is a set of steak knives
Third prize is "you're fired."
Nope. Writing better code generally requires more time. People will try to tell you otherwise, but either they're just off base, or they're confused by the fact that the amortized time of writing good code is less than of writing code as quickly as possible. That is, if you write all quick+dirty code, you reach a point each new feature you add takes much longer than if you had written all good code. However, at any given stage, it's quicker to write the quick+dirty code.
And of course, once you're in the hole and full of quick+dirty code, it takes extra time to replace it with good code.
"I am part of engineering team that maintains a very important component in our company [we'll let that slide, if your code is that bad and the company hasn't folded yet, it can't be THAT important]. Our code quality and general engineering quality focus has been very weak [don't do that. Even Ford says Quality is Job One, of course they make cars, which can be a lot easier]: we have frequent buggy releases [what? no QA department?], our latencies are shooting up [your code runs slower and slower - or your is taking longer and longer to get out, even without QA(see last)], our test coverage is nearly non-existent [Again, sounds like you need QA/QC tools], and it is impossible for a newcomer in our team to get up to speed and be productive in less than a month due to unnecessary complexity [any non-trivial code will take that long]. A group of 2-3 of us want to change that [out of how many? out of 4? out of 1000?], and we know what needs to change technically — the better code review and release processes, better build tools, etc. But despite that [so, despite knowing the problems, nothing is changed... I think you have answered your question], the quality of our code and design [both?] continues to suffer, and poor code continues to get released in the name of keeping the scheduled release date (product guys don't like to wait) [so, they are on commission, and you are on salary - win-win!]. We feel that if the right thing is done every time, we would can eliminate our issues and still release at the same pace [uh? so do it?]. How do we effect the social change necessary to convince them [who? the "bad" programmers? the "release-it-now" managers?] the of what is better [for who? your workload or their sales commissions?] and encourage them to take the effort to do it? [Similar to Q:How to make a million dollars? (paraphrasing Monty Python) - A:'think of a really, really, good idea, and make a million dollars!']"
This issue is a bit more complicated than you think.
As one who has plied this trade for decades, I'll tell you that programmers are human beings, just like everyone else.
We urge for recognition, and we need money.
You just do not tell us to do what you want us to do without recognizing the hard work we have put into debugging the products.
And you will not go anywhere if you do not pay us.
Muchas Gracias, Señor Edward Snowden !
it is impossible for a newcomer in our team to get up to speed and be productive in less than a month due to unnecessary complexity
The miracle worker. The mutant mastermind.
New to the team, Core component. Mission critical. Up to speed in less than a month?
A group of 2-3 of us want to change [things]. How do we effect the social change necessary to convince them of what is better and encourage them to take the effort to do it?"
Who is "them?"
Your supervisors or your managers?
More importantly, who are you?
Not the team leaders, quite obviously, and probably no more than a bare five to ten percent of the team, if that. Unless you have the social skills to build a much broader consensus for change, you'll get absolutely nowhere no matter how good your technical arguments.
In every other engineering discipline I can think of, where the word "engineer" actually means something, releasing sloppy and buggy work means you'll either get fired or sued. Possibly both.
Think of your products as buildings or structures. They have to live up to certain standards, have to work when they're put up (ever seen someone replace the foundation of a sky scraper after it's been built?) and have to be stable. Or worse - imagine chemical engineers who designed your drugs, or the mechanical engineers who designed your artificial heart were allowed to be as sloppy as software "engineers" are.
When engineers fail to do their work properly, the fixes are mostly lengthy and expensive, and often have to be paid for by the engineering company, and their products are withdrawn from the market (or buildings and structures closed).
As long as companies make a rule of flat out refusing to make and schedule engineering quality work, I refuse to consider their employees engineers, regardless of their education or working title.
If you have a Ph.D in astrophysics, but you work as a janitor, I'm not going to be calling you Dr. either.
The changes that helped our team overcome this were:
1. Code reviews are required for every single checkin. Establish a minimum standard criteria to meet for reviews, and hold people accountable.
2. Make a requirement that every code checkin must be accompanied by one or more unit test checkins, otherwise the code review automatically fails.
3. Our team held contests and offered incentives. This worked especially with the overseas teams in India and China, who were more than willing to write unit tests in an effort to win an iPad.
4. Reward those who show that they are dedicated to improving code quality.
Results will take time. It took about a year to see results, but they were HUGE. And that first release after implementing these changes was just the start of several successful releases.
The answer is complicated. If you don't have the pull to get the approval to prove what you want to do, you need to look at it from this point of view. The first question you need to answer honestly for yourself is "Does it make business sense to do this?". Answer this question as if it's your money and business on the line. If it doesn't you might as well drop the idea now. Otherwise, you need to consider whether or not you can actually do what you're proposing without getting fired for not delivering on time. If you're really concerned, you could figure out how much you can do and still deliver close to on time, to make improvement over time. In this case you want to make sure that the improvement is noticeable and attributable to you at some point.
My point is.. If you can remain employed, and make a change that positively affect the bottom line of the company you work for and ensure that tat gain is attributable to you, you will remain employed there.
It's essential that you get time to rewrite/refactor the bad code. If you want to keep the current release cycle where features are churned out as quickly as possible you will never, ever, have the time. Tools and processes can help, but the mentality of the programmers is much more important. They have to feel like they own the product and that its successes and failures reflect on them also.
You need to make the time available to your team to be able to do this. One of the first and easier way is the various security scanner. I'd be very very surprised if everything is clean if you complaining that the code is not good. This can easily get you a few weeks to fix the issues. That time can be use to get rid of some of the worst design practices and improve things for the better. Of course you'll have to see how management would react to such a thing.
Where I work, as a lead of a team of about 7 developers, we've finally managed to convince the 3 layers of management that a major rewrite was needed to release the next round of "must have" features. The project was started 4 to 5 years ago and was the victim of major feature creep, and that a lot of developers were left to themselves on the code, in a one man team situation.
One of the main arguments we were able to present, and I think ultimately what got us the deal, was that we had a version that was mainly stable on its own without any recent major incidents. This reassured the management side that they would still be able to make money while we work on a much better and much more designed version, while taking into account all of the experience that the team learned over the development of the last version. Some of the features that we cannot implement in the current version are also major blockers to the continued growth of the product.
As part of this, one of the major new things that we'll be introducing to the team is basic coding styles that will be enforced by Jenkins (for example, no HTML in a model, no SQL in a view, automated SQL injection testing). Specific modules will be owned by some specific programmers, but we're also going to force everyone to work on components which are not their own. One of the main goals is that anyone will be able to jump into anyone else's code and fix/improve things.
You also need to see if there are some roles that are adequately filled by your current team. Having programmers in charge of multi TB databases is usually a receipe for disaster. Same goes for complex algorithms and systems administrations. If you do not have access to specialized people in the dba/SA fields, you could probably justify hiring one or 2 more people to take some of the work away from the programmers.
Another tip, do not have a QA team or people responsible for QA. As weird as it sounds, through my various experiences, I've found that programmers tend to be much more careful when they are clearly responsible and made responsible for not breaking things.
What you have are people who are apathetic about the quality of their work and who are in-fighting among each other. You already have formed an "Us and Them" (you mentioned that "2 or 3 of us" know what to do) situation which projects negative energy at the them side (works both ways) and further feeds the lack of a cohesive and collaborative space.
Here's how you fix it, find something beautiful about the people you work with and compliment them on it. Look for the positive in people and let them know what you appreciate about them, love the people around you. Give this positive energy to everyone around you and watch how the situation changes, watch how people feel compelled to connect rather than divide. Resist the covert struggles for energy and maintain your positive focus, eventually you will be surrounded with positive people who will all work well together and good ideas will materialize as if delivered by a higher power.
in essence, only love can kill the demon.
"The Most Fun Possible on 4 wheels" is at SunBuggy in Las Vegas
With out a doubt you need to be able to measure what works and what doesn't but the moment some first turns to any kind of standard or the nightmare word "metrics" you have already failed. Too many companies go through all the fads and all the silver bullets. They have scrum masters, and black belts in Six Sigma (I am not making up the black belt part) but the fundamental problems are not fixed. Often the first place to start is with communications. Who does communicate and who is supposed to communicate. It is great if the sales people can bounce stuff off the programmers in the lunch room and even better if the programmers meet the clients but once the sales people are able to direct a project the project will instantly start chasing rainbows.
The second place to look is the why? Software is made for two reasons, to make money or to avoid losing money. This allows you to boil down any "solution" to the money. So if the argument gets into religious territory such as language choice, OS choice, documentation, or even commenting style you can then ask, how does this either make us money or prevent us from losing money? So someone might say, such and such a documentation system is better when you can then ask, lets look at the cost or value of us having no documentation at all vs perfect documentation. After breaking it down you might find it is a huge cost one way or another and your decision is made for you. This prevents programmers from continuing to try and impress their long past CS professor and his insatiable demands for Hungarian notation. But as a pro-documentation example if you are routinely cycling in new programmers into a project great documentation can pay for itself in spades; but first you must calculate the cost of bringing a programmer into a project sans documentation and bathed in documentation. Did that documentation save more than it cost to produce; you might argue that a good documentation is low cost but again compare that low cost to the cost of not having it at all or having less.
So better engineered high quality code feels like a great idea but make sure that the value of increasing quality does not have a disastrous business result. A simple example would be if your company's business is famous for being first to market with each new feature. People might grumble about how it crashes quite a bit but that since they make $500,000 a day using each feature having it a week earlier than the rock solid competition is very valuable. So if you slow the process of delivery down by 8 days and make the software perfect you will be out of business in no time. This is all a bit extreme but I suspect your core business is not making software but doing something else that the software supports. So it is quite possible that your company is mildly irritated by the bugs but that they exploit the features quickly.
Personally I have found that unit testing on larger projects ends up speeding up deliveries but on smaller projects definitely delays delivery.
One bit of horrible experience that I have picked up over the years is that some great systems were built on truly terrible code and truly terrible architectures. The disasters were also legendary but more often than not the cost of the disasters still justified the speed to market of the terrible system. Some systems were then recoded after disasters and made great but often at the cost of many release cycles resulting in a business disaster far greater than the disasters prompting the recode. Often the best solution was to make the code base slightly less terrible and press on at full speed. I have seen this terrible code and it is just solid WTF but when you look at the piles of money generated you just get angry that your own "perfect" code didn't make you rich. But as a counter point I have seen systems so terrible that the disaster took out the company; but even there just a slightly less terrible system would have saved the company. (The example I am thinking of had no backups so they lost everything, POS, invento
If you're a worker bee your only option is in a code review. IMHO, code reviews are great. Except for the bozos that focus on where '{}'belong, how much and where whitespace should be, why you didn't comment the "widget++;" line, etc. Comments like "you're talking to hardware, when you malloc memory like that you need to ensure it doesn't wrap your address space" tend to fall below "u shuld use calloc insted of malloc".
Don't get me wrong, code reviews are great. But it seems 90% of the time, and I'm being generous, of code review time is spent in the "you need to put the { on a separate line" kinda crap.
If you're a manager (note: I've never been a manager), your options are to enforce where the '{}" go, how many comments you enforce, and decide Hungarian Notation solves all problems.
Hungarian Notation is evil and anyone who endorses it should enter into the deepest pits of spaghetti code hell.
Some people write good code. Some people write crap. Some very intelligent people write very good code that mere mortals can't understand. Most people who think they're very intelligent write really crappy code that happens to work at the time that mere mortals can't understand.
Flashing back to my college English classes, this is where I sum things up to prove what I'm trying to say. So. A reasonable coding standard is "knock yourself out, then use this indent template". No matter how obnoxious the coding standard you're forced to use (except the hated hungarian notation) is auto-fixed and a code-review actually has the chance of being useful.
I'm deliberately not mentioning the idiots who do things like "hardware register 0xwhatever = 0x42". I've worked with assholes like that and they don't see a thing wrong with that line of code.
Social changes are hard and difficult to enforce--the most reliable way is to thoroughly screen who you hire and, reciprocally, who you work for, both of which are moot points for situations like this. Therefore, I am going to enumerate three easy steps, albeit brute-force, that should help change the way you and your engineers work and think. Devious, yes--but wait on your judgement until you've read through the list, they're not all that bad.
I'm assuming, of course, that you haven't already done these things. If you have, there are many ways to take it to the next level: start using Bugzilla (or a similar tool) to track bugs and features; organize your documentation into User Guides, ICDs, and ADDs; define a small but standardized set of processes for complex challenges; etc. You get the idea--incremental is good, as you can't simply dictate, from top down, the behavior and practices of your engineers (unless... are you on a management track?). Of course, if you're in a CMMI-4 organization in which each person has their own HG clone of the primary code base, with your own QA and support staff, these are hopefully already in your rear-view mirror.
One additional practice I would recommend is periodic release cycles--that is, release a major version every year, minor every month (or some variation thereof), and include in each release only the features and updates that are ready. If you can get to a point where your schedule and release cycle is no longer at the mercy of your requirement creep problems or an almost-done set of patches, you will find the atmosphere becomes much more productive and stress-free; quality will skyrocket as a result.
Last but not least... I'm sure there will be many fine suggestions from knowledgeable slashdotters on this page. Pick and choose the ones you think will work (feel free to ignore all of mine, except this one) for your team / company / project--and when you sit down to implement them, don't expect to get away with 100% of your changes. Do what you can, what you are allowed, and what keeps you productive. Too many idealistic junior managers or engineers-turning-managers try to bring their 'brilliant ideas' into an environment where they simply don't work, and the lack of pragmatism leads to total failure of all of their efforts, when they could have gotten away with 60% (which is better than 0%). Throw in the vast world of methodologies, process monkeys, and paradigm acolytes, and you'll see why it's worth being cautious and flexible.
There's a decent Wikipedia article on it. Accusing your management of allowing one of the now-classic dysfunctional management failures to grow could get some discussion going.
If you want quality code, you must instill the following in each of your developers (These all happen to varying degrees in my workplace and I love it):
Read the book "Code Complete" and notice pitfalls in your own coding practices. Present key points you found interesting to the rest of the team.
You will test a feature or component that another developer wrote that will be released and do your best to break it into a thousand pieces.
You will conduct countless code reviews and your name will be tied to that code review. Every line is reviewed and countless bugs are caught this way.
You will create unit tests, system tests, or other tests as necessary for new or modified code, but there must be at least one test that proves the code works, and three that prove it can handle failure scenarios gracefully.
You will use code analysis tools to identify weak points in your coding style.
Your code will be self-explanatory, simple, and comments will be sparse and to the point.
Unnecessary code will be pruned as soon as it is no longer required for backwards compatibility, and it will be indicated in comment which future version of the software the unnecessary code may be pruned in.
You will write design documents that will be reviewed by other team members and must be able to be used to develop working code. Dependencies and details are exceptionally important to flesh out at this stage.
You will not be afraid to prototype, and you will not be afraid to throw away your prototype when one doesn't work.
Above all, a software developer's job is to reduce complexity. Keep it simple, or you're stupid.
Of course, quality standards only work if you monitor that they're followed and reinforce them with incentives. My workplace is intelligent enough to realize that quality is important and rewards those who make strides in this area with bonus money. The bright side is that quality pays for itself with fewer defects, fewer headaches, more uptime, and fewer embarrassing conversations with upper management.
We feel that if the right thing is done every time, we would can eliminate our issues and still release at the same pace. How do we effect the social change necessary to convince them of what is better and encourage them to take the effort to do it?
Write a business case showing how much these "issues" are costing your company, and by extension, how much your proposed changes is going to save.
Then write out clearly what you want to change, how much that costs, and exactly how those changes can be objectively measured (i.e. so someone outside can know if real change has been implemented or if only lip service been paid).
Then offer to put your money on the line, and offer to take a share of the P&L that resulted in this change you wish done, on the condition that the changes have been implemented measurably.
Make your presentation to your manager, his manager, all the way up to the big boss who is ultimately responsible for these related costs and profits.
Then let them decide. This is the most important part, your job is to do the work, their job is to make decisions. Don't presume you can do their work better than they do. If they decide against it, don't make a fuss, don't try to implement your changes by subterfuge, find another job if you wish, but respect that your management had made a decision.
Oliver.
It sounds to me like this is a group of 2-3 developers who want to improve processes, without (currently) support from the business, which just wants to keep shipping on time. If you can't get management support, you're going to have a hard time, so that's the place to start.
If your management doesn't understand the concept of Technical Debt and how it's costing the company time, money and reducing your agility and competitiveness, that's where you need to start. How to go about educating them is something that you're going to have to figure out for yourself, since you know the people and the context, but I'll give you a warning: people don't like to be told they don't know their business. If you try to approach it like that, you're very unlikely to be successful. And, frankly, unless the group trying to initiate the change is already among the top performers, and has a track record of successfully delivering, you're unlikely to be successful no matter how you go about it. So you first need to get the guys the management perceives as being their top contributors on board.
Still, if you can get the conversation started in the right way, technical debt is a concept that business people can easily grasp, because it so closely parallels the notion of financial debt. For that matter, you should make sure you understand it thoroughly as well, including the fact that it often makes perfect sense to take on technical debt in exchange for a business advantage which is likely to have sufficiently-large rewards. Never forget that the purpose of the code is to generate revenues, not to appeal to your sense of aesthetic purity.
But, technical debt slows progress and massively increases the financial impact of bugs. The interest will be paid -- there's no avoiding it or deferring it -- and as the debt grows it becomes a burden which sucks up all resources. If you can get your management to understand and agree on that, you've won, as long as you don't screw it up.
To avoid screwing it up, do not embark on a massive development process re-engineering effort. If you do, you'll fail. You'll delay the next release, cost the company large amounts of money and customer goodwill and completely undermine everything you said.
Instead, figure out what one thing you can change which will have the most immediate significant and measurable impact. Do that, show the benefit, then move on to the next incremental improvement. This is hard. It requires you to not only figure out what will help the most, but also how to measure the before and after states, and to ensure that your measurements won't be gamed or encourage counterproductive behavior. Also, spend a lot of time thinking hard about how to make the change in a way that will have the lowest negative impact on productivity -- because anything you change is going to hurt at least a little, in the short term.
Though you need to look at your own situation, my prediction is that the thing that will do you the most immediate good is code reviews. Automated testing is a bigger win, but has a steeper up-front cost and the value is harder to quantify. With a little care, it's easy to document the financial benefits of code reviews. But to make them work, you first need good code review tools -- sitting around a table with printouts wastes everyone's time and rarely accomplishes anything. Spend the time to find a good code review tool that you can integrate into your workflow, set it up, test and validate it and be sure that it's going to work well before you ask people to use it. Note that this is all a lot of work, and unless management is extremely enthusiastic you'll probably have to do a lot of it during evenings and weekends.
Once you have it working for a while go back and pull out a bunch of reviews and take some time to carefully analyze what kinds of bugs were identified and fixed in the review process, and try to estimate what it would have c
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Bad code = No pizza.
Why can't we go back to using jumpers to configure slot adapter cards? Why? I say!
I'm a product guy these days. I used to be an engineer and have been a part of some great teams and some terrible teams. I've moved onto primarily being a product guy these days.
Here's the deal. The people who are telling you that the ship is sinking are right. You basically are at an inflection point and you need to see if the ship can be righted. There's a good chance it can't. If your analysis shows it can't, I'd suggest moving on.
The reality is that your practice, either by poor internal quality controls or by product/exec externality, is broken. What you need to do is bring this cost to light. If you're not using issue tracking with good graphing and analytics, it's time to. I know a lot of people hate it (I'm not in love with it) but you can get a good sense of these things through JIRA.
What you're looking for is per release cycle (and adjust/augment this as appropriate for your business, this is a sketch):
- How many man-hours total are available?
- How many man-hours are spent on developing new features?
-- What is the trend over the last couple releases?
-- What is the trend as new members are added to the team? (look for nonlinearities)
- How many man-hours are spent repairing defects?
-- What is the trend over the last couple releases?
-- What is the trend as new members are added to the team?
-- Are defects generated by specific subsystems? Can that code be refactored and made more modular to (ideally) increase robustness?
-- Are there individuals whose code/area of responsibility/general work generates more defects?
- How many man-hours are lost due to specs & tickets that aren't locked/defined before the development cycle begins?
These are key metrics to have on hand. Can you demonstrate losing more time to defects? That's a strong case for automated testing - but it needs to be presented in the context of losing efficiency on the team, not what's generally perceived as engineering being fussy about theoretical perfection. Losing hours on end to bugs - and to seeing the problem grow despite team growth - is an emergency and needs to be resolved.
I would focus on things that directly and immediately impact your ability to be more responsive - automated testing, strategic narrow-scope refactoring, etc versus pair programming, long formal reviews, etc. You want to buy yourself some initial breathing room and prove your point. If it sounds like fighting a fire, it is.
Finally, never underestimate the value of culling bad performers from your team. The most amazing thing I ever saw was reducing an engineering team by half and seeing its productivity quadruple... and no one was working longer hours. The bad performers/cultural non-fits were shown the door, given references and generous severance, and everyone else relaxed and found their groove.
Without more specifics and knowing your team it's hard to say more. You need to present the cost & tradeoffs. If management learns they're losing an engineer or two or three every release cycle to patching dumb bugs or fixing incomplete/feature-missed code, it's an eye opener. That's hundreds of thousands of dollars that are just being set on fire.
Ultimately you don't strictly have an engineering problem. Yes, there are things to improve, but your team is being overcommitted by product and/or exec. Your team (and your manager) need to be really transparent about the bandwidth. I guarantee it'll open eyes.
Force the programmers to work first level technical support for 6 months after release.
Two or three people in a large company can't change jack shit. This type of change can only come from the top. And the chance of that happening is zero. Do what I do, grin and bear it.
You shouldn't look to change others, only look to change yourself.
If you feel the quality is not good enough, start doing things that lead by example. Convince people of the value so that they want to change themselves.
Leading by example is the only way, you can't lead from behind. You need to show people how it's done. If you aren't showing them how it's done, then you need to up your game before you run your mouth.
The question presumes that developers are choosing to write crappy code and just need to be convinced to write good code. That's silly. Either they're capable of writing good code and want to, or they're not. If you have to convince people to write good code, then you have poor developers.
That's not to say there aren't external factors that degrade the maintainability and robustness of the code, and the questioner suggests things are rushed to get stuff out of the door.
You can try to get management's agreement to terms regarding technical debt (that is, that time will be given post-release to deal with technical debt). If this cannot be agreed to, or the managers reneg on an agreement, then you can just start estimating your work upfront taking into account (a) the effort it'll take to do things with minimal technical debt, and (b) the refactoring of existing crud that you'll need to do in whatever areas you'll have to work with.
Things like improving new team mber ramp up time are fuzzy and speculative. If you can make the improvements you want, then you can look back to see how those improve. Gather that data so you can advocate for more changes with some data to back your arguments, including the value to the company in saved hours, increased turnaround time (after the initial investments for undoing the crap that's already there).
Above all, prepare to go the extra mile to do the sorts of refactoring you want to do, including spendig long hours. If you're not motivated to do that, then you should ask yourself if you really care enough about the product/company to make that level of personal investment. If not, then learn to coast by their standards, or seek another team/company that provides the work environment you're looking for.
Stop sucking!
We have a similar issue at work, the Oracle dev guys make changes in production without proper testing/QA, approvals and logging, our Enterprise Security team is now (secretly) inserting tools to monitor all changes. When we has a major release a few years ago the code was so buggy that they threw not one but two superdomes at it to resolve the issues. Throwing hardware to resolve software issues. Yeeeaaaahhhhh.
The way we've started on this is making code quality visible. Using something like TeamCity you can get a coverage percentage - then write it on a whiteboard so all can see. If it's 3.00% it's a start. The reason I like coverage as a quality metric when you've got nothing and have to pick a quality metric, the coverage metric rewards deleting code and simplifying code as well as writing additional tests. Deleting code is overlooked usually on these high pressure environments but it's just as essential for long term maintenance.
Why stop at one quality metric? Because a man with two watches never knows what the time is.
Once you've got your project showing it's coverage %age, why not have a high score chart on a whiteboard / wiki page showing who's winning? Gamification / competition between teams can really help spur on everyone to focus on code quality.
"...we would can..." - seems to be a bug right there.
You need a Test Bastard.
The truth is: If it isn't tested, it doesn't work.
So hire or appoint someone who will sign off on your software either working or not, who will accept the blame if it doesn't work, and who will construct and execute tests or manage the team that does so.
Anything else is wishful thinking.
Show that poor quality leads to lost customers. If it doesn't affect revenue no one (who writes the cheques) is going to want to spend money on it.
I think not enough people understand that coding is just a small part of producing a working software system. A system starts with an idea in someone's head - when this is formally documented, we often call it User Requirements. Now note that that system already exists, although not in a machine-executable form, but as a vision in someone's head. So formal software lifecycle processes usually define various levels of documentation/specification. Each of these refines and details the previous level. So each level already represents the system, but starting at a very abstract ("in the head") level, until you get to the very concrete ("machine-executable") level. (QA/testing runs in parallel, ensuring that the product at each level complies with what was specified (the product of the previous level).
Enhancements also start as enhancements to the User Requirements and down the process, it is just an incremental addition, which is obviously a smaller work package than the original system. I don't have any experience of Agile methodologies (as you might be able to tell - military market), but if that is your environment you might be able to adapt the above, and allow for the tweaks that make Agile what it is. In effect most Agile methodologies have a lot less levels, and also divide work into a lot more but smaller incremental enhancements, enabling one to go through the remaining levels much quicker. Either some Agile or the older more formal methodologies are good, it depends on your circumstances which would be better.
What I'm saying is that changing the coding to be better alone, is like giving some paracetamol to someone with a brain tumor. Your way of working needs fixing, and it will probably not only involve your coders but all people in the process starting from the people that provide requirements - since everyone works on some level of abstraction of the system. Formalized processes are sometimes helpful in this, as it can be a standard condition of employment to comply with company policies and procedures. In effect, you need to turn your team from a collection of individuals who do much as they please, to a single organism that is "better than the sum of its individual parts" (see "Heterozygous" for a biology analogy).
Furthermore, all the above documentation can be helpful to newcomers (and existing employees) to get up to speed, since one can select the document at the desired level of abstraction and learn what you need to know at the quickest speed. Reading code (even good clean code), being at the lowest level of abstraction, can be quite time-consuming and frustrating.
Now it IS a big problem to get people to write good, to-the-point, unambiguous documentation - documentation that is as terse as possible and still verbose enough to contain everything that is needed - and that can be understood by someone other than the author.
Now to your question: (1) Do developers/employees in general, perceive that there are problems with the way they are working? If they are unhappy, then they might be more open to change that would improve their experience, than if they are quite content. (2) Once they are looking for improvement, it might be shown to them in the form of published work ("best practices") on this, or other companies' way of working, or even a small "pilot study" team in your own organization. (3) Many possible solutions exist, some contradicting others, and your org needs to find the one that will best work for them. I would say if people can provide input, they might be more accepting of the solution. Of course, an organization consists of lots of individuals so management is needed to provide (some) direction. (4) Be open to adapt/tweak for further improvements. (5) Use some carrot and stick to reinforce, but be careful of polarizing management vs employees - rather try to have people praised or censured by their peers, even if it is just weekly voted "biggest boon|booboo awards" that sit on someone's desk but don't do much else.
Free, as in your money being freed from the confines of your account.
Easy, you already identified the root of the problem: "product guys don't like to wait". Means you're in a company run by marketing/sales-people caring only for their commissions and next quarterly bonus, not quality-minded people who understands the business of building software. Probably you don't have the power to replace/educate those guys. That leaves you two options.
1. Apply for better jobs elsewhere. You can be a bit picky since you already have a job. Easiest way to end your suffering ;-)
2. Be a professional and convince the rest of your team the same. My philosophy when managers want to rush _every_ release out yesterday regardless of quality instead of just the occasional genuine crisis, is that their "average" instructions, however they formulate it, must be to produce a quality product. Ignore them breathing down your neck, throwing childish temper tantrums etc. They obviously don't know better. In the long run your way will provide them with more timely releases. Half a year from now they won't have less urgent planning, so you better have the code continuously in good shape.
Here is a good presentation on what to do: http://www.infoq.com/presentations/Erlang-Scalability
But there is a short description, if you want to innovate you have to write prototype code. If you want somebody else to be able to work on it then you have to make it more beautiful. Then you can have somebody come in and make it fast.
If you break it down and segment who works on what face then you will be able to convince somebody in charge of change, unless he's pointy haired and then your screwed :)
Promise them that if they write good code there will be cake after they are finished!
The biggest problem is.... what is good code..... It's all in the eye of the beholder, and I've seen it so many times, that what one programmer calls good code, another calls big crap, and vice versa..
When is something good code? NO THAT DOESN'T MEAN FOLLOWING SOME RULES YOU'VE READ IN A POPULAR BOOK ON CODING....
I've been trough this several times in Real Engineering (steel, not software)
1- You explain to your manager that you barely make it as it is (there are bugs - things could be better at deadline-time)
2- Your solution is to do SOMETHING ELSE than to work on the production part -> things will be worse at deadline-time
3- but don't worry, after a while it will get much better.
You need to eliminate nr.2
Get an external resource to do the tool-improvement and create the practices. It can be a student or someone cheap, because your team will do the steering and planning, he/she does the gruntjob. It will seem to your manager that there is only improvement, not a worse situation with a promise of better days (also realize that you have to avoid nr.2 by contiuing to work as usual during the change)
The only way of producing good quality code that I know of, is by introducing rigorous quality assurance, and by management realising that code is not ready for release until it has passed all QA tests. Not meeting deadlines is a minor sin, releasing unfinished code is a major one.
QA is something that should be integrated on all levels:
- When developers estimate the work, they have to learn that it takes much longer than you expect; even if you can accurately estimate how many hours a piece of code will take, you have to take into account all the overhead, like meetings, context switches, breaks (and that IS important!) etc. 30% of effective work is probably all you can realistically sustain over a longer period of time. QA in this context means that you compare your estimate to how long it actually took and change your future estimates accordingly.
- Code must not be checked in to source code control unless accompanied by unit tests etc that demonstrably work as expected. Many source code control tools can check this automatically as part of the check-in.
- The product must be integration tested by a separate QA team, whose only purpose in life is to break your work. They musst not be developers, because developers will know too much about how to work around problems. All integration testing must be carried out on non-development systems, so you are not unwittingly relying on development libraries and environment settings that your customers don't have.
There are tools that can help you with this process, but really it is about management discipline, and ultimately about sustaining a good business. After all, if you take money from your customers and give a poor quality product, they will decide that you are liar, an incompetent - or both. And then they'll go away and give you a bad reputation.
pay them well, let them work. don't do either, and you'll get bad code - you can count on it.
peer pressure. (Seems I have to actually write something to get past the filter when really two words are all that is needed.)
Chain them to their workstations with no food or water until everything builds and all the tests pass.
Any questions?
You don't convince them, you educate them.
Joel Spolsky wrote a number of articles, years ago, that are really relevant. I'm going to link to and quote some of them:
The Joel Test: 12 Steps to Better Code:
1 Do you use source control?
2 Can you make a build in one step?
3 Do you make daily builds?
4 Do you have a bug database?
5 Do you fix bugs before writing new code?
6 Do you have an up-to-date schedule?
7 Do you have a spec?
8 Do programmers have quiet working conditions?
9 Do you use the best tools money can buy?
10 Do you have testers?
11 Do new candidates write code during their interview?
12 Do you do hallway usability testing?
Joel says you should be getting at least ten of those twelve. Sounds like you aren't. So, next article is relevant:
Getting Things Done When You're Only a Grunt:
And those are:
"Strategy 1 Just Do It", setup a build server, write the make file to automate the build process, etc.
"Strategy 2 Harness the Power of Viral Marketing", setup your own bug tracker. Use it for your own bugs. If someone sends you a bug in an email, add it to the tracker and reply saying that it would be so much easier if the person just added it directly to the tracker themselves. Setup local version control. Use it. Etc.
"Strategy 3 Create a Pocket of Excellence", be excellent. Write specs and follow them. Write schedules and follow them. Etc.
He continues with "Strategy 4 Neutralize The Bozos", "Strategy 5 Get Away From Interruptions" and "Strategy 6 Become Invaluable".
Another article Top Five (Wrong) Reasons You Don't Have Testers explains that you need an independent Q&A team with real power, while Things You Should Never Do, Part I says don't throw out code and rewrite from scratch and Incentive Pay Considered Harmful says what it says on the tin.
Browse around the site and read some of the other articles as well. There is a lot of good advice there.
HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
When someone tells me my code is bad, I look them straight in the eye and say
Is my code bad, or is it BAD ASS. Aw yeah.
Your good code can be trash for me, and vice versa. The code that is excellent into the situation X can be horrible if used in the situation Y. Stop looking for "the perfect coding style that fits all," it does not exist.
Religion: The greatest weapon of mass destruction of all time
Talk them about Kant and the Categorical Imperative. Transpose those moral concepts to coding and there you go! I tried that once, not sure how much difference it made, though...
As long as the company (management) is pushing strongly for pushing new releases fast, then there is no solution to your problem. You can ask for a "day of zen" where all the programmers go off-site and discuss "what is good code" until everyone is fired up, only to return to work and get back into the old mode. The todo list and release dates hasn't changed.
In terms of "good code" there is of course never any excuse not to have properly written, formatted, and commented code etc. I am assuming the main problem with your code is it is somehow poorly architected and quality checked; bad or inconsistent design, commit stuff as soon as things seem to work, avoid spending time on writing tests - that sort of thing. New stuff gets layered on top or some quick band aid is applied, and it eventually turns into a big mess.
For that kind of code problem, "fixing the problem" is a big thing. It is in itself an investment - the poor development processes has incurred a development "debt", which requires man-hours to fix. Lots of stuff may have to be rewritten. And in return for all this time, product managers are getting no new features to show the customers - "only" a more stable product. Secondly, new stuff will (in the short term) take a little longer to implement, because doing it right takes a little longer, plus various problems with the old code will surface that need to get fixed. Thirdly, the team's mentality towards what it means to write a good product needs to be changed - and some of the team members may not be able to change their attitude, or may not have the skills to write and architect proper code.
In the end, this is a problem that needs to be discussed with the powers in charge, as a big and serious issue. While it may be comforting for management to let things just run as they are, this is the type of approach that leads to complex and unmaintainable products. Which at some point, so much debt has been incurred that product is completely unstable, everyone is caught up in "fixing" bugs and crashes, and new features take forever to fix even when trying to take the quick route.
Unfortunately, with the typical near-sighted "next quarter" focus, it is an uphill battle you may well end up losing.
As I understand the problem is:
a) Code is buggy
b) Management has head up ass
This results in:
1) poor functionality leading to poor user experience
2) a slow on-boarding process
The goal is:
i) Get clean code
ii) Extricate management head from ass
A potential way to approach mangement is to "share" the problem with the appropriate responsible manager. Make your problem their problem (can often be done just by point out the proble.
Indicate that the current on-boarding process takes at least twice as long as necessary and point this out to the HR manager. More time spend on-boarding directly impacts the productivity of the unit (the trainer and the trainee waste time), and therefore is wasteful. Show much much can be gained by cleaning up the code.
Indicate to the Customer Service Manager or Sales Manager that customers are dissatisfied. See if you can get access to customer complain logs and estimate how much is being lost to competitors due to poor functionality. Do a Customer Lifetime Value calculation and show that by cleaning up the code, a customer's loyalty will increase by X months or years.
Then do an ROI calculation. Estimate the amount of time it will take for your team to clean up the code. Estimate how much that costs the company (salaries, workplaces etc). Show an earn-back period. If you can get it to show less than 1 year earnback, then ask the HR manager and the Sales Manager to step to sign their name to your solution and ask them to help you present it to the General Manager.
You need to get on the radar to the GM with the clear proposition of: Save money, serve customers better, make this a better place to work (retain employees).
What needs to change is that you need to reward good quality instead of punishing it. "Good-Fast-Cheap. Pick any two" tells you what you need to know. If you want good then your management MUST understand they will have to pay for it. Either by allowing the time to create good work or paying extra money for it. Management's job is always to minimize those things. They therefore always punish quality work.
Your focus is too small. Get the big picture right and the small stuff will take care of itself.
Good luck, you'll learn a lot while you fail.
Looks like you are using Fast & Cheap.
I've worked as a dev in 7 different companies from seat of the pants deployments to SEI-5 rated teams and everything in between.
There was 1 team of 7 devs that didn't have any QA, no mandatory testing, no real process besides using RCS for version control. They were all personally responsible for their code and considered any memory leak a huge bug in the code. We supported 10+ platforms. In 3 yrs, I think only about 20 bugs were reported from the thousands of users.
At other places, we had more process, more testing, QA, bug databases, and we would have 20 bugs reported every day. I did my best as dev lead to introduce negative reinforcement for negative results. Breaking the build, too many bugs, simple oversights - all had negative outcomes that were known before. I had fresh-from-college devs on the team so we used peer pressure to teach them. One guy liked to include every file in our project inside his code. Compiles took forever. His new name was "Captain Include" for the next 3 yrs. The other team members taught him when it was necessary to include each file AND about forward declarations. His code wasn't really buggy, but there were other devs that constantly broke the code even with what appeared to be high productivity on all other measures.
I did have individual "productivity" measurements and stats for each dev, but I never shared those with my bosses or the team. That would have destroyed the trust. There was no relationship between amount of code written and bugs introduced in our data. It really was very individual. The GUI devs had 4x higher bug rates than the non-GUI guys. They were also less experienced devs with only 1-2 yrs while the back end guys were 5-10 yr devs.
At the SEI5 project, we didn't make too much code. It was critical that everything work perfectly. Our bugrates were tiny - 1 every other year, plus there were 7 levels of testing including from outside companies. Government project, obviously. We had so much overhead for documents, reviews, testing, builds that I can't imagine any commercial company doing it. Not even heart pacemakers.
Any function that is longer than 1 computer screen is too long. Seriously. There is something about having a unit of code all on the same screen that can be well-tested. This makes code much, much,much less buggy.
Also, throw out the IDE. These monstrosities hide too much from devs. Instead of writing clean, clear code, they are screwing around with IDE crap. A minimal editor and makefiles is what we need.
. But despite that, the quality of our code and design continues to suffer, and poor code continues to get released in the name of keeping the scheduled release date (product guys don't like to wait)
If you want to change things, then you'll have to fail to keep to the scheduled release dates, or release buggy software that causes client issues that come back into the account managers that appear to be running the company's development schedule despite not having any knowledge of good software development.
But first you have to express clearly to management that the current poor software development practices are going to lead to this issue, that it won't be long until it will happen, etc. That's so you can say "I told you so, and I told you the solution" when you enact the above plan.
But ultimately if it's only taking a new guy a month to start being productive, then your problem isn't that great right now.
In a small company that I worked, we opened the code for the client (the client has a code team and in order to convince the client to purchase our product, we offered the code for them, and then we got a deal). This fact (the client developers will check our code) make all the team code better. Open the source code, in some level, automatically make you write better code, cause you start to think "omg, what others will think about this? and my reputation as developer?".
wow, one should not need to convince why doing quality work is important :O
Just leave that company, or get all of those who oppose doing quality fired. There really is no middle solutions in situ like this.
Pulsed Media Seedboxes
I worked at one place that fired all the programmers nearly every two years. Bad programmers come and go. So what. I worked there nine years until I quit to go to another company when I wanted to leave. If you cannot take over a project, figure out what is wrong and correct it, then maybe you're not the great programmer you think you are. Here's how to become a better programmer. Realize first what is good code, it isn't the code style, you can use a code beautifier to change that. It isn't in the comments. Although good programmers recognize when a well placed comment will help. Good code works. Support calls decrease. You can demonstrate that to a non-technical boss. Why was I still employed when they fired all programmers every two years? Because often I was the sole programmer on a project and it didn't fail. If they had a project that failed, they gave it to me and after a few releases it was fixed. So secret number one, the reason you right unit tests isn't because your boss forces you to do it, it is because you recognize that your work is your reputation. So what if you aren't given time to write good code, you're not given time to write bad code, are you? Don't even commit your code to the repository until you have tested it. Study programming, and I don't mean like you did in school, realize that professors like to teach, programmers like to program. Find a good programmer and look at his code. If there are no good programmers in your company, look at open source. Lastly, recognize that becoming a good programmer takes years. Learn a little about metrics, it will help you to show your boss that your projects are improving while you are becoming a better programmer.
Reward good behavior and push people in the direction your trying to go, get rid of the people who are blocking your attempts to make things cleaner.
but the attitude may be that way because the typical demand is "push push push" until the goal is met, I see a lot of people fall into this trap where they believe that if they can just get to "X" we'll be O.K. and we can stop making the developers life hell. If that's the case then its a managerial problem, the environment will tell you a lot about how things operate day to day.
Good leaders run toward problems, bad leaders hide from them.
It is in 90% of the cases impossible for an employee to improve something his manager does not see as necessary.
The other 10% of the jobs are worth doing.
You can:
1. fetch the money, feed the kids and stop complaining
2. find one of those 10%.
Yes, this answer is exagerated in a cynical way.
I just got fired on a project for doing this. The inevitable outages and downtime when cleaning up a 10 year old mass of hand-built, undocumented systems caused me to revamp and document the systems, but encounter some very bad failures. (When there are entire databases, subnets, user accounts, and critical production software running on developer's desktops that no one in the company has ever documented or even backed up the machine, there are going to be outages as you do cleanup.)
The newer engineers there are doing a much better job now, partly due to my technical leadership and partly by my taking a backhoe to the documentation and throwing out most of the outdated and irrelevant material. And they were all shocked as I left the building. But when management wants 24x7 availability, new features all the time, and gives no time to do it, something's got to give. They've taken my good work and hung me out to dry because I discovered a lot of the existing "dry rot" in the project and cleared it up, but yes, it cost time and political capital when services went offline in the cleanup. They'll now get a few years of stability, and they won't be paying my senior engineering rates and I won't get stock when they go public next year. That kind of thing is why I make damn sure I get paid in real money, not just "shares".
So, a critical lesson for me and for you, is to spend the political capital in advance to get managerial buy-in to the project, or be ready to move on if someone doesn't like any aspect of your work. Outages and breakages are *bound* to occur as a result of the cleanup, at least at first. If you're like me and do your work because you love it and want everything to work, do it but be prepared to be unloved by some parts of management. Publish if you can: publishing your work in open source projects so others can benefit from it, and so that you've got verifiable achievements on your resume, is priceless.
Everyone seems to be focusing on money, but the truth is that to help your team develop a better code the first step is not to raise wages but to BE THE EXAMPLE,
Write decent code, show the good practices to your team and REVIEW the team code, this is the key to motivate and guide the developers team.-
This video clip says it all:
http://www.youtube.com/watch?v=LvwqK2gn3S0
* Carthago Delenda Est *
There are ways to instigate a change without being loud about it. When you write your code, write it pretty, well documented and with great unit tests. When you are releasing, write good release notes. When you are in charge of a feature, do good code reviews. Make code review templates. Write good documentation. See what happens.
If you really want to put this on the corporate agenda, you need to convince the person making technical decisions. If this gets on his or her agenda, things will happen. Beware when approaching this person - you've been thinking about this for weeks or months, while it may be quite a new idea for them. It may take a while for things to sink in. Don't expect it will happen quickly, or even the way you think is right. Plant the seeds and tend to them as they grow. Be prepared for resistance among coders too - writing docs, tests and releases are rarely seen as very compelling work, especially with tight deadlines.
Before doing anything though, you need to think about how important this is to the business. To you, it may seem like a very important thing and a complete no-brainer. However, you may not have all the information necessary to make this decision for the business. To the product and business people, the opposite may equally seem like a no brainer. All they care about is that it does the job and hits the market when they need it. Tech leaders are often enslaved to this kind of stuff.
Also, in my experience, many times a rewrite / major refactoring ends up costing too much and producing little benefit in the long run. Old idisyncracies are replaced by new ones and key sections of the code - often most critical to the business - end up scarred by changes around them and not better in any way. Be prepared to encounter people with similar experience and perhaps a bit of resistance along those lines.
Outsource. All you will find in the US is what you see posted here - whining about more money and that's why they code poorly. Like giving them a huge raise would make the quality any better. The moment someone says they can't do a better job due to money, they need fired. Once you show you can make a good product (code or service or whatever), you get paid to do it well. Your developer bubble burst over a decade ago, get over it.
If by "Product" people, the OP means sales/marketing people, then this will be a constant problem, the development team will always be to blame, and you will always feel like a cross between Sisyphus and a dung beetle.
First, you will need a development manager with the authority to hold the release of a product version.
Second, you will need a development manager with the backbone to stand up to pressure from the "product" people and push back.
Third, you will need a development manager who protects you from the "product" people who are used to coming to you directly and dropping tasks on you.
Fourth, you will need a development manager who will inspire your development team to change their coding habits from fighting fires to development based on a plan. Whether than inspiration comes from higher pay, a kick up the arse, threat of firing or good old-fashioned physical intimidation/sexual innuendo is dependent on whatever works on the individual developers.
Finally, you need all of those development managers to be the same person.
Once you have that person in place, they need to adopt a specific development methodology - Scrum, Agile, fundamentally it does not matter at this point. You are starting from such a low level of code quality that it sounds as though just about anything will be an improvement, as long as all the developers are pulling in the same direction.
The development manager sits down with the "product" people, establishes a list of required features for the next version, and either talks to the team about estimated development times or comes up with that figure themselves. Add time for comprehensive testing and bug fixing (not all bugs, just the major ones), plus a little extra time. That gives the release date. Product people want it sooner? Fine... what features shall we take out? Once the feature list and timeline is established, if the product people want to add features or change their mind, then either the release date is moved or those changes are held over to the next version, or other pre-agreed features that have not yet been developed are held over.
The development manager will be the most hated person in the office for about 6 months, and (s)he will need the full backing of the company directors because you can be sure that the product people will be on the directors' cases 24x7 complaining about the obstructive person. It is not an easy job, it is not a nice job, but it is one that I have done at a couple of companies, and once the product people see a release come out on time and relatively bug-free, they will start to come around.
Who gets laid off first, the guy who writes quality, modular, well documented code on which he has instructed his teammates on the functionality? Or, the guy who creates such a mess that no one can figure out what he's done? The guy who writes quality gets laid off since his work is easy transferred to another person or outsourced.
One thing I've learned from our eastern European and Indian colleagues is there's no PERSONAL advantage to writing good code or knowledge sharing. They're from a dog-eat-dog world where survival depends on defending your turf. Defending turf means writing code that you only understand and sharing the bare minimum with others.
In the USA we've grown up in naive academic world where helping others and creating quality for the common good is a moral virtue. That was fine decades ago but the market is far more competitive with international engineers from a world of bare-knuckle tech brawling.
Hold the company you work for hostage with arcane systems, hold your managers hostage with bewilderingly complex code, and politely don't help your co-workers. These are the keys to prosperity:)
As long as managers and other leaders give shit about Quality (in many ways, not just from an "external" point of view), absolutely nothing will change.
The guy needs to change the people above him and we all know this will never happen. Most businesspeople are money whores and they hire coding whores to be their bitches. We, the programmers, have absolutely no dignity left and will do whatever the money whores demand. That's the said truth and all We Bitches can do is to change our pimps to feel a bit more comfortable.
I think there are four things you need.
- commit to quality (has to be top to bottom)
- use systematic process (seems like you get this)
- check everything (at every stage)
- improve continuously (own your process and your meta process)
i wrote more about this at http://www.multicians.org/thvv/nasty.html
well, I think a relatively straightforward approach would be to have them tag-team assignments. not the resource you're talking about, but individual subroutines/functions. if you can afford the individuals' downtime, have them rewrite the code from scratch. have pairs work on one subroutine, but not simultaneously. half way through the initial writing phase, force them to hand off to their partner without the benefit of a handoff or status briefing. when they realize that they're taking more time to interpret the code than to finish it because it has obscure variables or function calls or zero commenting, they'll start doing it on their own. it would speed up the process if you made inputs from the individual coders fold into an annual review.
The quality guru Joseph Juran wrote about this issue fifty years ago. (See "Quality Management" by Mr. Juran, I've taught this subject using this book for the ASQ, and used it as a working QM). Pick your fights; find a product team that is motivated to try a better way ("early adopters"), and give them your best effort. Do whatever it takes to make them successful. Once you have a success story, tell that story to less motivated teams. Juran claims what once a change has been adopted by 20% of the company, it takes on a life of its own and the change is invevitable. Enlisting the help of a single upper level manager (a "coach") is essential, but you probably don't need more than one.
Good luck!
- Ex HP QM
Solid code needs to be engineered, not written. Very few people understand that today. It is the reason why so much code is straight garbage today. Unless you can get everyone, including management, to understand that actually writing the code is a relatively small part of the equation then you will never, ever, ever succeed in getting your company to churn out anything but bug-ridden, undocumented, untested, garbage.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Of course management will try to offload responsibility to "technical experts", as much as they can. The term is SCAPEGOAT.
I am 99,9% sure it is not engineers at fault, but engineering management, who have failed to establish proper processes that ensure
A) Quality of Architecture (i.e. not having serious conceptual bugs)
B) Code Quality (i.e. not having outrageous coding practices)
C) Quality Assurance (Close to 100% code coverage from testing, realistic test cases, regression tests, comprehensive and rigorous testing procedures before release, comprehensive testing of new features)
D) Quality of Documentation (complete, correct documentation of 100% of features, QA on documentation, too)
E) Source Code versioning
F) Versioning of Test cases and test code
G) A proper bug tracking system and proper QA checks of allegedly fixed bugs
Many if not most managers are cynical and lazy bastards who care 99% of time about their next powerpoint presentation and 1% about actual issues and the fixing and testing of those. They delegate all the hard work and "focus on communication".
Nobody's posted this yet?
http://xkcd.com/844/
Just to reinforce what others have said - code reviews (even starting small) and independent QA is essential as a starting point. Make the quality of the code a source of pride.
Been at several such places. Tried to improve things. Failed miserably every time. Got fired, hard, once, for even trying to bring up the subject.
You need a commitment from WAY ABOVE. You usually don't have that and can't even get permission to talk to that person. Even if you do talk to them, I've never seen them swing the Titanic around. Sometimes a few half-hearted words and namby-pamby window-dressing gets done, but that'as about it.
there's a way.
If they suck at their job and write shitty code they should be fired.
Harsh, I know, but code improvement methods are not rocket science. A programmer who writes a single unit test that essentially does nothing but let the programmer say, "Hey, I unit tested this code!" is a programmer who needs to be shown the door. Ditto for the programmer who won't add the "Why I did this" layer of comments, or the programmer who consistently overlooks error checking, anomalous inputs or other obvious errors. For that matter, I would (and have) booted programmers whose idea of a help message is "Error on Input Block 40!", OK? A programmer who doesn't understand human factors is frankly, incompetent at their trade.
Please do not read this sig. Thank you.
I realize such an endeavor is both daunting and expensive but you may want to assess your list of issues around this topic. I've worked in several mature products and the differences are quite startling. Good architecture not only prevents issues from getting in but encourages great code.
If you don't have a detailed architecture document, this would be priority number one. As you write this document you'll also be building up a laundry list of the uglies.
Some of the interesting findings I've seen in past:
1. Duplicated code. Usually a symptom of lacking modularization or lack of architecture training
2. Change complexity - to add relatively simple change, too many files are touched. could be due to over engineering or the lack of one.
3. Slow builds, hard to configure and test. high time for componentization. cut down on the dependencies. create mocks and emulators. implement dynamic loading/plug-ins. basically, optimizing dev testing cycle results in more testing, and better code.
Engineers and engineering companies frequently fall into the trap that a product must be "good" before it can go anywhere. Often leads to an endless cycle of perfection without actual release.
The OP seems to be in this mode. They could instead release a quick, simple version of their work, make it functional, and then iteratively build toward the ideal "good" as needed. Has the bonus of making product marketing happy too, as they get an early look and can say whether that was what they wanted in the first place.
If the code isn't good, NO SLASHDOT FOR YOU!
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
As one who has plied this trade for decades, I'll tell you that programmers are human beings, just like everyone else.
We urge for recognition, and we need money.
You just do not tell us to do what you want us to do without recognizing the hard work we have put into debugging the products.
And you will not go anywhere if you do not pay us.
If we need recognition in order to do work of acceptable quality, we have an ethics problem. For people with a sense of professional ethics, recognizition and remuneration are pre-conditions for staying at a company or project. But they are never pre-conditions for doing developing software with a professionally acceptable level of quality. Professionals leave, when the time is right, when they feel unrecognized or underpaid. But they do not deliver shit.
Barring the unavoidable hacks that must happen here and there, software professionals with work ethics do not deliver shit even when unrecognized or underpaid. The greater problem in the software industry is not the lack of recognition (and certainly not the lack of good pay). It is the scarcity of developers with a sense of work ethics.
Ask Slashdot: How To Convince A Team Member That Thinks The Code We Write Isn't Good?
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
/* loops forever looking to see if a message queue exists,
* looping every 10 seconds to see if it exists
* if it does it continues in the program,
* otherwise it loops forever */
This is an example of how to write an effective comment that explains what's going on, how the structure works and why it works the way it does, most code I've seen wont even put that comment there, leaving a new team member to have to look at it for a period of time longer then needed to figure it out. I also think people don't comment enough, a comment should be at any line that isn't simple enough where a non coder can sit down and figure it out with in a few seconds.
So in my opion, focus on making effective and good comments, not a ton of code structure, formatting, characters in a line, editor to use etc... etc... etc... and NEVER include spelling. Any developer who gets mad at a spelling mistake shouldn't code, a spelling mistake that doesn't break the code doesn't matter. Spelling errors matter in documentation and legal defence not code. Also overall have fun, I find alot of standards have no fun in them, locking a standard into a military strict format just takes the fun out of coding, having to worry about every little thing with no freedom doesn't help to create an effective coding enviroment.
One has to note that different settings certainly require different quality standards. Avionics and medical instruments certainly require extremely high quality while nobody is really hurt by facebook fucking up.
Office software certainly is between these two extremes, as information security is concerned (spearphising attacks etc).
But for many companies it is exactly O.K. to ship lots of new features with shoddy quality, as their products will be bought and installed anyway, Nobody has seriously punished Adobe for delivering crap all the time, for example.
I went through this very thing when I first started at the company I work at now almost 4 years ago. The company was fairly small, but was in the process of significantly growing (when I was hired, it was about 20-30 people, now it is around 70-80). The software manager, who I had worked with previously and had brought me in, wanted to bring in better processes including test plans, unit tests, continuous integration, common tool base, etc., had just recently started at the company, was overwhelmed with work, and had very little support from above and below. It was bad. There was no QA. There were no dedicated testers. There were no unit tests anywhere. Plus, the company was on the verge of a fairly large increase in the number of projects that needed software support, and had just suffered a fairly catastrophic failure of their core product on a major project (the company would have folded if it was a product company, fortunately as a services oriented company it was able to remain afloat and even profitable over this time).
The way we have approached it has been to incrementally improve things over time. I would say there were very few wide sweeping changes done.Little by little, we added personnel (a dedicated tester was added right away, a QA manager 2 years ago, and a senior tester one year ago). Little by little, we improved processes (added a Development Guidelines and Practices wiki-page to outline how we do our work right away. Created a development environment setup procedure. Slowly and continuously developed build, installation, and deployment procedures. Maintained design documents by adding a little to them each week, etc.).
On the development front, we started using Bugzilla, adding it to the core work flow - you did not write any lines of code without a bug (either issue or enhancement) being in place first. The code base was spread across Java, Matlab, Embedded Linux applications, drivers, and kernel c and c++ code, as well as custom firmware originally developed by a 3rd party contractor in c. A re-write would be impossible, and like the original poster, there would be no way to meet deadlines if we were to do it. We put in place a release process, and integration test plans for the core products. We also started to better utilize shared code between projects, adding a "common" pacakge for Java code that is built into every application, and a shared repository for both the embedded firmware and Linux source to share algorithms and processes between them.
Our approach on improving the code quality was 3 fold:
1) Brought in unit-test frameworks for all software components. C-Unit for embedded c, TestNG and UISpec4J for Java, slowly built up unit test firmware binaries for the custom firmware code. Note that this was done over the first 2 years, not all at once. The embedded firmware was core to our company, so we started there. Any new code developed would always have unit tests created for it. If we had to fix bugs, a unit test would be created to re-create it before fixing it.
2) For old code, we slowly cleaned it up. It was simply a mess, especially the embedded firmware. It was basically a giant pile of monolithic code with no concept of modularization or testability. Our approach here was to slowly evolve the code into a better design. If we found a bug, as noted above, we would add a unit test for it first. When we fixed that bug, we would spend an additional 2-3 times the amount of time fixing the area of code affected, both design and implementation. Slowly, the code became more modularized, more robust, and much easier to work in. We can add features in half the time it used to take, with far less bugs and much less
3) Any new application were done right from the beginning - incremental releases, unit test coverage, test plans, etc. It was a slow process improving what already existed, but new projects. Developers who were not onboard with this were phased out, with new developers hired to replace them.
I would say it probably wasn't until about 2 ye
Start your own company selling the same products they offer and steal all their customers with promises of better releases. Or just sit back and realize that if the product is selling, then that means people are willing to pay for it which is all the "product guys" care about. Not mention if you are charging for support, there's another revenue stream to leech off of.
It sounds like you are too much of a purist to be working at that company, I wouldn't bother with trying to inspire a revolution as you have to convince the execs that there is an ROI pot of gold at the end of the rainbow which can be next to impossible to prove. A software company that doesn't value things that are inherently designed to make the product better are like knife sales people. They don't care if the knife cuts 1 or 100 tin cans or leather belts or whatever, as long as you buy the knife. So if they say "our goal is to sell 20 knives" and the sales people sell 20 shitty knives, and you go to them and say "but these knives suck!" they'll say "maybe, but sold 20 and met our goal!" My advice, bail.
My view is that deadlines generally are arbitrary. Sure, you can have firm deadlines when it's based on regulatory mandates, threats of termination, or similar things, but many deadlines I've dealt with were simply pulled out of someone's behind (typically someone in management). Ideally, your team should have the opportunity to strongly influence deadlines by offering a realistic work plan based on level-of-effort estimates, dependencies, and so on (yes, you can do this even in an "agile" environment). BUT, the key is to temper the typical developer optimism and be as realistic as you can
Whenever I hear "metrics", I think "Beancounting". Intellectually challenged managers and the "just stick to process and all will be OK" idiots think they can somehow delegate responsibility to some sort of brain-dead statistics.
Shitty software will be discovered by capable development managers when they run the sw, when they execute their little suite of test cases, when they run their little testing/validation perl scripts. And YES, capable development managers are NOT powerpoint/excel jockeys; they are engineers (with authority over other engineers) who care for their product. They do that by USING the product.
But actual managers are very often lazy, intellectually challenged bastards who would like to delegate everything except the collection of money to their underlings. They are too lazy to perform even the most basic form of quality assurance themselves.
You are using a process and you want to change it to a new process. The process here consists of people. The developers on your team always make a choice. Although they are used to understanding things in a certain way, and to reacting to stimuli in a certain way, they can change instantaneously if they think they are better off. So if you want to change your team understand your team and your environment, bring out your findings, advocate new behaviors with a compelling cost-benefit analysis, train people in the new behavior, and then monitor.
Install sonar, run it on your codebase (assuming it's a supported language).
Install the technical debt plugin, show how many bugs a robot can find, and how much technical debt you have.
technical debt = money not spent for fixing bugs not fixed, that a robot could find but your developers could not find.
That will put a price, literally, on your problem.
It sounds like the biggest problem is your product guys and their demands. Honestly, who cares whether they're impatient? They'll get whatever they can out of you, so you need to start changing the conversation, and reset their expectations to reasonable levels. (But obviously, don't explain it to them in those words.) If you get pushback, explain (to your boss if necessary) about your quality concerns, and how the code has gotten progressively worse, buggier, and slower over time, and demonstrate that you have a clear plan to reverse that over time to improve the product. If you and all your engineers are on board about changing the process, you can make it happen.
On the engineering side, every code change should have 3 steps to get it into the repository (you're only doing step 1 right now):
1. Write the code
2. Write the unit tests (and/or integration tests) or update existing ones
3. Get the code through code review, making changes if necessary
On the scheduling side, you should include estimation before agreeing to any dates, and that estimation should account for all 3 of the above steps, and also QA testing.
Finding a unit testing framework is easy (JUnit, CppUnit, FlexUnit, etc), and you can include it in your build process. It can be optional on developer machines, but turned on for your automated build server, which emails the team if a unit test ever fails, and whose checkin caused it. It's also helpful to have a daily code coverage report (we use Cobertura for Java) emailed to everyone. When you start seeing percentage graphs of your overall test coverage, and that your own portion of the codebase has much lower coverage than someone else's, it's a great motivation to write more unit tests, and to fix the bugs you find as a result.
For code review, I've used Gerrit (for git repositories) and Review Board (for general repositories). You can have either convention or automatic enforcement that every code change must be reviewed and approved by N other people. It's really helped my team to be more consistent, and to write things well the first time.
For an automated build server, I've used Hudson. It's able to run the unit and integration tests, and make a new build or deployment for every code checkin.
To help your upstream problem, here's an example conversation with your product team.
- We need [feature] by [date].
- I can get you an estimate tomorrow of when we can finish that feature.
- No, we need it by [same date].
- I'll include in the estimate what we are actually able to finish by that date.
Or another example conversation:
- How long would it take to do [other feature]?
- Well, writing the code, creating unit tests, and getting through code review will take [duration].
- What if you skip the unit tests and code review? Those don't sound important.
- Sorry, our automated tool chain (or our engineering process) won't let us do that, for quality reasons.
- But we really need it by [shorter duration].
- Sorry, we really can't do that. It sounds like we'll just have to cut that feature.
1) Realize that management is most likely not the solution, but may not be as much a problem as you think. Managers tend to think in different terms than code quality, but understand that code quality is important in an abstract way. So they won't tend to initiate code quality practices, but they may be open to what multiple engineers tell them they need to do.
2) Initiate code reviews. I think there are two optimal ways to do this. One is pair programming aka continuous code review and the other is group code reviews. If you do group code reviews every Friday order lunch and have people what they present what code they wrote. This practice will also serve as a "code camp".
3) Incorporate code quality measures into your build that spew out reports. Tools like NDepend or Crap4j can give you rough measures of code quality. You can make sure these metrics do not increase or set a goal to increase your overall quality by X/timeUnit. This actually requires a lot of buy in however, because many managers and QA groups don't want you to touch code.
Kill all the product guys.
No, seriously. Murder is probably a bit overboard, I suppose, but get the hell rid of them.
Or make them explain to you, and as many of their bosses as you can get in the room, why they prefer shipping a bad product over shipping a good product. When they bullshit a non-answer (they're product guys, they're used to being able to get away with vague mumbled buzzwords), call them on it. Publicly. Point out, for all the managers in the room, the tradeoffs caused by their approach. (Managers don't generally like to admit that tradeoffs exist until they absolutely can't avoid dealing with that fact any longer, so this is for their benefit as well.) Ask their boss, in front of them, why this behavior is seen as acceptable, given the long-term damage it is doing to the company's reputation and the additional labor costs caused by not getting it right the first time. Make sure this is all done as publicly as possible, and in front of people who (a) have a stake in the company's long-term success and (b) have the authority to set things right. Then, either the people with authority get rid of the chaff and allow the reasonable ideas to thrive, or they double-down on stupidity and fire you. But either way, your problem is solved, because you don't have to deal with them.
Though I suppose, for all that work, a concrete-shoes approach might be more efficient and have broadly similar results.
see https://wiki.jenkins-ci.org/display/JENKINS/The+Continuous+Integration+Game+plugin :)
Continuous integration, together with a basic set of automated tests, ensures good quality all the times. And the game ensures that all participants want to get a good score
Maybe you can add some (very basic) static code analysis - just some rules where everybody agrees that they are essential for good code.
There are a lot of ways to improve software quality. Some are cheap and easy. Others are hard and organizational.
If it's just you, and you don't have strong management support, you'll have to start small and build up a group of allies who think as you do. Demonstrate how quality code is written instead of just asking for it. Mentor people to help improve their skills, and spread it. If you need the quick and showy splash of a new initiative, hire a new software engineer from outside the company who already does these things, and who is willing to help you implement them.
John
The On-Board Shuttle group is (was) even more bad-ass than that. For them, 5 9s (99.999% failure rate) was unacceptably lax.
FTFA:
Yeah, right.
"it is impossible for a newcomer in our team to get up to speed and be productive in less than a month" That's cute!
I work for one of the worlds biggest SW companies, you'll never guess which, an it really doesn't matter. When I started they told me; dont expect to be able to do anything useful within the first 6 months, and it'll take a year before you are contributing. Sure.. I beat those estimates, but not by all that much. You be happy with what yo've got!
The fundamental problem is that this is a religious issue for both engineers and managers. People generally don't believe until they personally witness the miracle of rapid development with predictable schedules and low customer visible defect rate.
Working solutions in order of increasing time + difficulty:
1. Quit and either start a new team or join an existing one with decent development practices (I insist on a code and test process walk through of every company I consider joining to avoid unpleasant surprises. Obviously this fails for groups yet to build a product, and sometimes teams panic when pivoting and abandon reasonable practices).
2. Get promoted to a leadership role while you remain hands on. Tell every one else to do the right thing like you're doing - getting people to buy in is easiest when you're not making them do something you won't like the case would be with a non-coding manager. Most people fall into line with direction from above. Peer pressure works for most hold-outs. Any one not getting with the program can be replaced.
3. Do the right thing on your code. With your process producing a faster more predictable release cycle you'll have higher productivity and can take over an increasing fraction of the product so the bad people with bad process have less impact.
Applying test driven development variants to new features/subsystems/products helps a lot here because it makes shipping without good test coverage and short predictable cycle times impossible because no product code exists without the necessary infrastructure. While a "code complete" milestone may be farther into the future depending on how that's defined the total time to deliver the project will be lower and ultimately it's the ship date that matters.
Do the same for bug reports. Every reproducible bug gets an automated test case (if it broke the first time it's complicated enough to break again).
After a couple years you should be in good shape with enough infrastructure that the cost to add test cases is effectively zero before their benefits are considered (Perhaps most notable is that the requirement for incremental testing leads to cleaner interfaces which make complexity more linear with respect to project size. That in turn produces a lower defect rate, faster turn around time on repairs, and makes defect rate/time to repair more constant and predictable) and you don't have to worry about new people (or old people who haven't touched a piece of code in a while) breaking things accidentally.
Here are some things which don't work:
1. Talking to your co-workers about doing the right thing
2. Providing anecdotes (personal and otherwise) from other companies about the benefits
3. Buying everyone a copy of a book like
_The Clean Coder: A Code of Conduct for Professional Programmers_ by Robert C. Martin
http://www.amazon.com/The-Clean-Coder-Professional-Programmers/dp/0137081073/
Quote:
The jury is in!
Te controversy is over.
GOTO is harmful
And TDD works
in their choice of print or Kindle edition with the direction to read it on "company time."
4. Doing the right thing and providing metrics on things like defect rate, time to repair certain classes of bugs, number of release candidates for a feature, etc. This can be very striking - memory corruption bugs made reproducible by the test environment so you fix them in 30 minutes versus three weeks for co-workers' similar bugs, a major subsystem with no QA or customer visible bugs or just one of each, etc.
Logical people would get on board after seeing such evidence, but this is about religion not logic.
Have a regular chin-wag about the ugly stuff seen on thedailywtf.com
I hate to admit it, but it is true. You probably won't find a way to fix this company. Work hard while there, but find another job. Soon.
Once a company gets into the downward spiral, the bean counters say they can't afford 1 minute or 1 dollar that doesn't produce direct revenue. Management and bean counters set the features and delivery dates too tightly, quality slips further, and it just gets worse and worse.
Before the crash and before I was forced into early retirement by yet another round of management hired in to try the latest whiz bang development paradigm I described it to management thus: We are being shot at with BB guns. One hit won't kill us, but 100,000 will, and it is a very painful death.
What was once a 200 man company now exists as a one man fire fighting shop trying to keep customers, inside what was a fortune 500 company who's capialization has shriveled to insignificance.
Give them good requirements.
Seriously, that's the hardest step. Once they know exactly what's expected of them, down to every line break and full stop in the dialogs, good code should be a cakewalk.
Techtard 421, why aren't you at your post? Return to your workstation immediately--you are not qualified to be a leader. Leadership is outside your skillset. That is all.
I used to work on a project that shows some similarities. Ad-hoc coding, feature creep, heavy time constraints, overly complex code, ... Don't expect miracles. If you start with a heap of dung, it is never going to smell good.
I sent an e-mail to my manager detailing 4 of the most critical problems. Fortunately, he was wiling to hear them, and we made some changes that improved the situation. But when I left there was still a scheduler (to start and stop machines at specific times) that was never rewritten. It was funny, the day I left I found the e-mail again, and then I heard a fellow-engineer had been assigned to make a trivial change to it. Expected amount of work: two weeks.
If the problems lie deep, it is wishful thinking that you can simply fix it. In a perfect world, you would start over again. In reality, there are all sorts of constraints. Here are some tips:
Analyze the project history: try to discover what files are changed the most, what kind of changes are mostly requested, are there modules that produce a spray of bugs whenever they are touched etc. (you do have a bug tracking system, right? If not, get one now!).
With that analysis, try to isolate some pieces of problematic code. Remove all sharp objects from your desk while doing this, because you might want to poke your eyes out. Focus on a part that changes a lot and see how you may fix that. To give an example: every time new menu options had to be added, the guy who wrote that became pale and mumbled something and went off to implement it. A few days later it became available, with some bugs like wrong menu's popping up. So when I tried to find out what was the problem, it turned out that every goddamn menu-item had a hand-coded position ID. so if a new item had to be inserted, all the next menu's needed their id's to be incremented, and all references to those id's updated. Using some rather advanced macro's (including concatenations), I managed to clean that up. It's not cleanest solution, but it only took me 2-3 days to implement, and after that, new menu's could be added in no time and without bugs. Also, anyone could add them.
What I want to say with this: you may improve the situation without making extremely drastic solutions. If you make just a couple of such changes, these can already have a drastic impact on development time. More importantly, it will not go unnoticed, and change the dynamic of the team and management. People will start asking the right questions: how can we further improve the situation? At that moment, your voices will be heard much louder.
If there are no test cases (as was the case for me too), you have to reconcile with the fact that it's too late. Try to add test cases for new modules, but realize that retro-fitting unit tests to a large project with low-quality code is not realistic. The next best thing might be adding assertions wherever you encounter bugs. Also adding sanity checks (e.g. testing if large object trees contain valid data) may prove helpful in debugging.
I hope that helps, and best of luck.
Any further criticism/advice is always welcome.
"It's too bad that stupidity isn't painful." - Anton LaVey
Your team members are clearly not feeling the cost of their failure or the benefit of better practices. Schedule a 1.5 hour meeting where you go over the worst code that week and the best code that week. When bugs show up in a release track them back to the developer(s) involved and rename the bug to include their names.
Identify WHAT DEVELOPERS NEED TO LEARN OR CHANGE during each code review and provide the resources for them to learn the better practice.
Pay bonuses for good code and good practices. If you're afraid that some people will quit... don't be.
Every rule has more than one consequence.
Been down this path many times and all it does is cause endless self-grief and hopelessness, primarily due to lack of upper management support and resistance from peers. I will tell you what has worked: get in on the ground floor of a project as the tech leader, establish and ENFORCE "good" quality and process standards. You may not become "best buds" with the others because of this, but they'll either toe the line or move to another project or company. Either way, the project will be better for it.
This goes a long way in describing what motivates us.
http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=youtube_gdata
I agree, code reviews are the best way to identify shitty code. What if the code is bad, but the bugs aren't really provable? Let me give some examples.
I've seen this happen, especially in old code. The code works, but it's full of 2,000-line God Classes, dangerous half-objects, and doThisThatAndTheOther() void methods. Young developers are happy with it because it works and they continue writing the same kinds of idioms.
Arguing for change in code this bad will require a rewrite, which is hard to justify if you can only find potentially dangerous behavior vs. real bugs. Your only argument comes to, "Yes, the code works, but down the line this catch Exception block could result in unpredictable results." Folks who don't have years of answering to customers when these problems manifest don't see the danger.
Shirley, someone else must have been in this situation before.
You make it sound like the default is to intentionally right bad code. Bad code (or the opposite of writing good code) is PRIMARILY a result of externalities that are NOT under the control of the programmer. The MOST COMMON is lack of proper specifications, project planning and management!!
If you write bad code we will cut off you curry supply. Should do the trick for most coders.
Writing good code isn't just writing clean elegant code with state of the art tools. Programmers have to be fundamentally convinced their code works. Quality assurance people have to be fundamentally convinced they can break the code. If your company is willing to take formal QA/QC seriously, QA needs to be established independently. Set up a small QA operation, make sure they are trained to learn how the code and interface should work better than the end users, send them to a quality assurance refresher course if needed, and give them "teeth." The CEO has to be enthusiastically involved and supportive if you're going to get a healthy and productive balance between two independent departments.
These days we've shown that an abstract singleton factory method bridge prototype facade is the only way to go for maximum flexibility!
You know, I just stopped to wonder what one of those would look like, and after a moments reflection realised thst you just came up with the prefect description oof the spring framework. :)
If they believe they will be in the same job in the future and may have to revisit the code they produce, that gives incentive to make decent code.
Tell them that if the code fails, they will be the one to have to fix it at 3AM.
Having a separate group fix the bugs, is a Bad Thing. 8-)
I fully understand what you mean, but unfortunately, "code is complex" is a very subjective statement. Something complex to you may not be complex to your team member. So, everyone need to arrive on a common ground on what is considered "complex."
One widely accepted metric to measure is complexity is the cyclomatic complexity or McCabe complexity. [http://en.wikipedia.org/wiki/Cyclomatic_complexity]
There are free and open source tools to compute cyclomatic complexities of your code base. Using a tool, you can find out complexities of functions, files, directories (by adding that of files) etc. Then find the top-10 in each category. My favorite is the top-10 complex functions.
Install a cronjob to perform this computation every day.
Track which functions are increasing complexity.
Have all this information readily available in a intranet website and share that link to the team (couple of times!).
I am pretty confident (have done it myself) that this will bring some improvements (may not be as much as you want).
As bad as it sounds, as developers, we are not building the next Taj Majal and our code will not withstand the test. What that means is, code is obsoleted every 2 years if not sooner nowadays. So, I say, write code to make things work and move onto the next project. Frameworks and unit tests just aren't agreeable to most middle-managers when there are serious deadlines that involve $$.
I have been fighting this battle for years and I finally gave up; it simply is not worth my time to try to convince the management why we need more time on projects for unit testing, uniform development and things like PSR-1/2 standards. I followed the "standards compliance" paradigm for a long time and still lost. So, give up and just make things work as best and as fast as you can - we are also all replaceable by outsourced development. Just some thoughts.