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.
Strippers and blackjack
Make good code or no rice.
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
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
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.
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
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.
"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?
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
If as the submitter claims "new people take a month to get up to speed" then either their project is trivial or they are doing something right.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
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 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.
He's not for hire as a perm. He's a consultant.
Science advances one funeral at a time- Max Planck
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?
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
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.
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.
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
One man's clean code is another man's over-engineered rubbish. The industry is not as united on the definition of "good" code as one might expect it should be, and in my (lengthy) experience with developers of different temperaments, there is great variance in how code is received and evaluated.
The standard of judgement that gets applied to code is not objective, and never will be. It cannot be, as coding includes art as well as science.
Trying to force your preferred coding style on to developers who operate differently will never end well. Unless you are uncommonly versatile, adapting yourself to a standard you hate will also not go well.
Find a job where the programmers evaluate code similarly to how you do, and you will be much better off.
As an aside, I have worked with developers on both ends of the spectrum, and found that both extremes are equally bad in different ways:
1) Hastily-written code makes the trade show date and wins business, but can really ruin a company's reputation when the app doesn't scale and the bugs drive clients' costs through the roof. Contrary to the beliefs of those who write such code as their standard MO, constantly delivering maximum value in minimum time is NOT sustainable in the long run.
2) Writing very clean code, and then keeping it clean, does NOT save you time in the long run. While it does reduce bugs and (in theory) makes it faster to add features in the future, the length of time it takes to write the code in the first place exceeds the time saved by fewer bugs, and the future features must also be clean, which *always* requires more refactoring than you would expect.
Successful businesses will find a happy medium between these two extremes, much to the chagrin of developers who earnestly believe one extreme is better than the other.
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
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.
Try proof by counterexample.
If you're using C++ make a "fun" header file and hide it in an automated build script.
#define true false
#define false !true
#define if while
#define continue break
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.
A better option is to study the Plan 9 source code or read the Practice of Programming.
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!
Start with teaching the employees the importance of writing good code.
Also teach them how to refactor code in the IDE they use to avoid gigantic monolitic methods/functions/classes.
Then provide them with the tools. In addition to compile at the highest warning level and using the built-in support in the IDEs they should look at Stylecop for C# (even though it's more about style than finding potential bugs), Splint for C, FindBugs for Java.
People that are willing to take in and understand the importance of writing good code will end up being better.
And don't forget that people are competitive to some degree - so if you find a way to measure the quality of the code produced it's fine, and let it come with a small advantage. A movie ticket, a box of chocolate or something similar.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
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.
"...we would can..." - seems to be a bug right there.
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 :)
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....
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.
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.
In general (meaning they are exceptions, a lot of them) engineers are not good at coding. Good coding is more of an art and math science are the mediums, and the computer is the pallet. Part of good coding is to make your code elegant, small and easy to follow. I tend to prescribe small applications that do one thing and do it well, over the large program that does it all. Then combine these small apps together in a unified UI, this makes each piece easer to debug because you know what piece is doing what. However that be the case (performance, tighter integration, etc...) that you need to make a larger project, similar rules apply, make it easy to navigate. Know where the code stars and how to follow it.
But the biggest problem I have seen is because coding is an art form people get too personal with their code and try to protect it when it is time for it to go. So we end up with a bunch of code of different styles and ages that have been over reworked to be a hindrance, where a remake would be better.
Get rid of code that has many different ways of doing the same thing. Avoid third party libraries that are not standard or where you don't have the source too.
Try to maintain a coding standard, and have someone review the code at random intervals to make sure they know what is going on. Some people try to put enterprise development designs into a small app making it too bulky. Conversely some people try to code like it is a small app in an enterprise app, making it less uniform. You just need to watch them and keep them implace and Change behaviors before it is too late
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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?".
Trying to force your preferred coding style on to developers who operate differently will never end well. Unless you are uncommonly versatile, adapting yourself to a standard you hate will also not go well.
Also, when developing, realize that having consistent code that matches the rest of the project is far more useful than having a small chunk of code that - to you - is slightly more readable in and of itself but dissimilar to everything else. Most (although not all) coding standards, after all, are relatively trivial.
With Java, at least you have the official Sun recommendation to start with which almost every project follows somewhat. I prefer to operate as a diff of the standard - "Follow the guidelines, but lines up to XX characters are fine", for example.
2) Writing very clean code, and then keeping it clean, does NOT save you time in the long run. While it does reduce bugs and (in theory) makes it faster to add features in the future, the length of time it takes to write the code in the first place exceeds the time saved by fewer bugs, and the future features must also be clean, which *always* requires more refactoring than you would expect.
A very good point. If your code is well compartmentalized this gets even less efficient - if you have a big hairy ball of code that only gets tweaked once a year, but each "5 minute" fix ends up taking a full day of testing and hair-pulling, spending a month or two to fix it just won't ever pay off, especially when you add in the opportunity cost of missing a month's worth of new feature development.
You're special forces then? That's great! I just love your olympics!
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.
I'd have to disagree with point 2. Writing clean code is not just about keeping to coding standards, keeping functions small, or even making a decent object model. It is also about making a system open and extensible by providing clean APIs, web services, mechanisms for adding extensions, function hooks, etc. That takes time and effort, but does reward you with a way to add new features faster. However, those extensions (new features) do not need to be particularly clean in themselves. Because the code for those new features will be isolated from the base code, you can get away by hooking a quick & dirty extension into your clean system. Such extensions are likely small enough to debug or change easily even if the code is messy, if you've done your homework on providing a well defined interface on the main system. Having a type 2 (clean) base system with a well defined interface allows you to add new features with type 1 programmers, delivering maximum value in minimum time, in a sustainable manner.
You don't want to find a compromise between the two styles, you want to find the right mix.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
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
Also, understand your role and the role of your company. Not every level of craftsmanship is appropriate for every level of project.
You're special forces then? That's great! I just love your olympics!
What the code review should cover, however, are standards like "Have your methods do the thing that matches their name, do one thing, and don't have any avoidable or undocumented side-effects." The nice thing about forcing correct (not too much, not too little) abstraction in a code review is that a) automated tools are terrible at figuring that out, and b) you've locallized your problems - if there are any - to code that can either be refactored if its a problem or just left alone and ignored if its ugly but effective.
You're special forces then? That's great! I just love your olympics!
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.
Almost amusing, but wouldn't the 1st 2 #defines cause an infinite loop in the macro expander of most compilers?
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.
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.
Kick them in the nuts. Now that you have their attention tell them to write good code.
And while you're at it, tell them that there are plenty of people in India who will be glad to write good code for $5/week, have 3 people on a team that properly requires 10, lay off 1 of them in order to instil proper levels of terror, make the remaining 2 work 70+ hours a week (salaried, of course), and just in case that doesn't motivate them enough, tell them that they must give "110 percent" and "work smarter, not harder".
I would say six months is the average period to get up to speed with a significantly large software project. In a month you might allow someone to make a trivial change to the GUI.
The Moore-Murphy Law: The number of things that will go wrong will double every 2 years.
Yeah, one month is a pretty small amount of time IME. Everyone sucks at their new job for the first 6 months. Any experience otherwise is probably a perfect example of the Dunning Kreuger Effect.
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.
I find it amusing (actually amusing, not being ironic here) that we both had similar comments but, with minor differences in interpretation of the GPP, posted them as agreements-with and differences-with the point being made by the AC above :)
You're special forces then? That's great! I just love your olympics!
If as the submitter claims "new people take a month to get up to speed" then either their project is trivial or they are doing something right.
I agree... a one month ramp-up time is totally insignificant assuming the shop has a reasonable turnover of about 5% per year. If there are a significant number of people voluntarily leaving on a regular basis, however, management might have other fish to fry. That said... smart people might want to leave a place with crappy standards, so management would have the best interests to create quality controls and standards.
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.
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
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.
there's a way.
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.
2) Writing very clean code, and then keeping it clean, does NOT save you time in the long run. While it does reduce bugs and (in theory) makes it faster to add features in the future, the length of time it takes to write the code in the first place exceeds the time saved by fewer bugs, and the future features must also be clean, which *always* requires more refactoring than you would expect.
That is an excellent point. But I would counter that the aim is not reduce time of delivery, but to control risk (and ergo, cost). As a business, I would prefer to know that something will consistently take me, say, 4 weeks, of testing and delivery with fewer bucks, than knowing I could "deliver" in half the time, but with a "hidden", hard-to-quantify, highly variable cost of defects, maintainance or extensions.
With the former case, I can consistently ballpark the cost and ROI. With the later, it's like driving while blind.
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
> Trying to force your preferred coding style on to developers who operate differently will never end well. Unless you are uncommonly versatile, adapting yourself to a standard you hate will also not go well.
The better programmers leave their ego at the door. As Neil Peart brilliantly said recently:
Q. I think that a lot of people are surprised to learn that you still take drum lessons. You're seen as this drum master by most everybody.
A. What is a master but a master student?
http://www.rollingstone.com/music/news/q-a-neil-peart-on-rushs-new-lp-and-being-a-bleeding-heart-libertarian-20120612
If programmers have that much ego, it is probably better that they leave since they have shown that they aren't interested in learning a different perspective. (This can apply to both the young-whipper-snapper or old-crotchy ones equally.)
Every time I was forced to use a new coding style I initially disliked it. But I always was able to put my ego and biases aside and ask myself:
* What are the advantages of this way?
* What are the disadvantages?
Only by understanding BOTH answers can one really grok what works and what doesn't work. The rationale is more important then the rules.
The same thing applies to naming conventions.
Likewise, I've worked on code where there NO getter-setters allowed at all, where you MUST write getter-setters (even trivial ones), and ones where there no trivial getter-setters. The 3 different styles made me appreciate the different trade-offs.
> 1) Hastily-written code makes the trade show date
> 2) Writing very clean code, and then keeping it clean
Yes, completely agree there are 2 extremes:
* Ship it
* Over-Engineer it
> Successful businesses will find a happy medium between these two extremes,
Again I concur 100%. A pragmatic programmer knows when to just "let it go" and when to "rip everything out" -- the code is good enough, and when to re-architect, re-engineer, re-factor, etc. because the original code no longer solves (or handles) a different set of requirements.
It is a tough balancing act but there is one general guiding principle.
If you can achieve the same solution with less code then that is preferred. Less code has less bugs, and less edge conditions.
Smaller code is usually more beautiful then Large code. :-)
Writing very clean code, and then keeping it clean, does NOT save you time in the long run.
There are different definitions of clean, but your definition is wrong. You didn't say what you think clean code is, but if it's taking you more time, then you are definitely doing something wrong.
"First they came for the slanderers and i said nothing."
As others have said or implied, the OP's question is itself incorrect. The actual question is about how to get management to buy in.
Have your management read the relevant sections of the following: (1) Steve McConnell's Code Complete, (2) Chris Sterling's Managing Technical Debt.
If management can't or won't learn these lessons, then I can't emphasize enough how correct the P, GP, and OP posts in this thread are.
There are many ways to have management terminated or shoved aside. Go to the targeted manager(s)' boss(es). Or go to the boss(es)' boss(es)' boss(es), etc. Go the board of directors. Go to the investors. Or if management has engaged in illegal activity, report them to the proper authorities, etc. However the OP goes about having his management terminated, he is morally required to do it for the long term benefit of the investors. The investors' long term interests must come first.
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.
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.
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
+1 for the Hungarian Notation. It only creates problems, if you don't know a variable's type you just use the code editor to find out. HN is only possibly useful if you use notepad for writing code, and even then I'm being generous.
"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.
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.
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.
I was going to say.. Around here, 6 months is "fast", 1 year is more typical.
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).