Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: How To Convince a Team To Write Good Code?

Soulskill posted about a year ago | from the cattleprods-are-your-best-bet dept.

Programming 366

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?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Sooo.. (5, Funny)

kiriath (2670145) | about a year ago | (#42664945)

Do you work for Blizzard?

Re:Sooo.. (4, Interesting)

phantomfive (622387) | about a year ago | (#42665505)

Heh, that raises a question. I often complain about other people's code, it's a typical developer hobby. I can name a lot of companies that produce lousy code, but

What companies do you know that produce good, high-quality code? I was depressed to find I couldn't think of many. Maybe Sun before they disappeared, and NeXT, before they disappeared, and SGI.

Easy (5, Funny)

Anonymous Coward | about a year ago | (#42664947)

1. Higher Pay
2. Good Management
3. Beatings

Pick any two.

Re:Easy (4, Funny)

Savage-Rabbit (308260) | about a year ago | (#42665113)

1. Higher Pay
2. Good Management
3. Beatings

Pick any two.

4. Hire the consultant in China who did such good work for that cat video guy [slashdot.org]

Re:Easy (2)

Cryacin (657549) | about a year ago | (#42665437)

All I would need is a hammer, two nails per developer, a roll of duct tape for every 3 developers a carrot and a monkey wrench. Oh yes, and the development floor to be on international waters.


From today's TheDailyWTF (0)

Anonymous Coward | about a year ago | (#42664949)

"We don't need more people; we need better people!"

Re:From today's TheDailyWTF (5, Insightful)

TapeCutter (624760) | about a year ago | (#42665311)

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.

JackBlack Strippers (1)

Anonymous Coward | about a year ago | (#42664955)

Strippers and blackjack

Send them to North Korea (1)

Anonymous Coward | about a year ago | (#42664959)

Make good code or no rice.

Fire your boss. (0)

John Hasler (414242) | about a year ago | (#42664973)

And perhaps his boss as well.

Re:Fire your boss. (0)

Anonymous Coward | about a year ago | (#42665227)

Thanks for the for your ingenious input. We will take it into consideration, and even possibly hire you to replace our bosses, for your ability to make excellent decisions.

Stop pissing in the wind (5, Insightful)

Anonymous Coward | about a year ago | (#42664981)

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.

Re:Stop pissing in the wind (4, Funny)

NevarMore (248971) | about a year ago | (#42665353)

Like, the brand of air conditioner in the office. Or the janitor.

My father was an air conditioner and put me through college you insensitive clod!

Re:Stop pissing in the wind (5, Insightful)

Austerity Empowers (669817) | about a year ago | (#42665551)

I view management as cogs too, they are fairly interchangeable, and on their own worthless. Put them all together in a bag and you get a percussion instrument. Percussion instruments are essential to music, and you can bang on them with sticks or mallets.

Re:Stop pissing in the wind (3, Insightful)

Anonymous Coward | about a year ago | (#42665611)

Other than doing as little as possible, I wholeheartedly agree.

You should work hard while you're there though, if for no other reason than because doing things the right way in the wrong environment is really, really hard and you'll learn a lot. Properly made code doesn't interface well with awful code, but it's a task you'll have to do at least occasionally for as long as you're a developer. Being good at that is an invaluable skill.

It's also nice to not feel awful about what you left behind, if you're the kind saddled with a conscience. Do it without complaining uselessly (you also shouldn't just hoof out the door without at lest trying to change things if you like where you're at), and you might even be remembered well, which is a really good thing when the economy shits itself as it occasionally does, or if somebody you worked with and respect later has an opportunity to recommend you for a better position.

You are doomed (5, Insightful)

Stirling Newberry (848268) | about a year ago | (#42664985)

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.

Re:You are doomed (0, Insightful)

Anonymous Coward | about a year ago | (#42665029)

it was a failure the moment i saw the following line: "I am part of engineering team"

no further discussion necessary

Re:You are doomed (0)

Anonymous Coward | about a year ago | (#42665543)

And its obvious you aren't.

Re:You are doomed (0)

Anonymous Coward | about a year ago | (#42665645)

I am not sure the purge is going to happen soon - revenue wise we are growing better than our estimates, and the overall sentiment in the camp is positive. That means the company as a whole is doing a lot of things right.

We have recognized that engineering quality is a problem and though it has not hurt us too much till now, it is going to sooner or later. Upper management wants to solve the issue. Director of my team is fed up of waking up in the night on weekends due to S0 issues (not every weekend, but for any "big" release, there is always this fear in his mind). Just that they don't want to seriously reprimand the engineers, but instead bring about a change where they start taking it seriously.

WTF (0)

Anonymous Coward | about a year ago | (#42664989)

Kick them in the nuts. Now that you have their attention tell them to write good code.

This does not bode well. (3, Insightful)

Anonymous Coward | about a year ago | (#42664995)

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...")

Create a presentation (5, Insightful)

eksith (2776419) | about a year ago | (#42665007)

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.

Re:Create a presentation (-1)

Anonymous Coward | about a year ago | (#42665221)

Your advice to help them stop wasting time is to create a power point presentation? Seriously?

Re:Create a presentation (1)

eksith (2776419) | about a year ago | (#42665403)

Who said anything about PP? And it isn't a waste of time to build a big picture of exactly what's needed, what needs improving and what needs weeding out. If they don't know what to change, how will they change?

Re:Create a presentation (1)

Anonymous Coward | about a year ago | (#42665443)

Management loves powerpoint - changing the delay between slides is almost like programming to them. Makes them feel like productive, contributing members of the department. Powerpoint is the right solution, methinks.

Learn how to code yourself (1)

NetNinja (469346) | about a year ago | (#42665015)

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? (2)

alvinrod (889928) | about a year ago | (#42665023)

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.

Re:Do you maintain your own code? (0)

Anonymous Coward | about a year ago | (#42665107)

yeah, i think as someone mentioned they are continually in the weeds. just add this feature or fix this bug as quickly as possible.
at some point the pressure from above distorts the engineering process so much all you can do is flail. as someone else
mentioned the people giving the orders have to be convinced before you can even attempt to instill an appropriate culture
in the developers.

the sad thing is, it done correctly basic quality measures will mean more features over time and fewer bugs.

my guess is that the higher ups think that if they dont keep the pressure on, software will just fuck around.

Hi, I'm In QA (4, Insightful)

cosm (1072588) | about a year ago | (#42665033)

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).

Your Friendly Neighborhood QA Tester

Yes a LOT more QA is needed also out side the box (2)

Joe_Dragon (2206452) | about a year ago | (#42665077)

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.

Re:Yes a LOT more QA is needed also out side the b (1)

Savage-Rabbit (308260) | about a year ago | (#42665375)

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.

QA (3, Interesting)

DavidClarkeHR (2769805) | about a year ago | (#42665197)

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.

Re:Hi, I'm In QA (4, Interesting)

Anonymous Coward | about a year ago | (#42665211)


Everything you wrote is correct and well taken. However, all the things you bring up are not nearly sufficient, and I would argue they are not even the most important. As an analogy, during the '60s, '70s and '80s Detroit automakers developed a reputation for shoddy workmanship. But they did spend a lot on quality control - tons of workers were assigned the job of "reworking" botched vehicles that came off the assembly line. And their dealers learned to do their own fix up work before moving vehicles onto the showroom floor. During the '80s, after the Japanese and Germans started kicking Detroit's butt, a slew of quality consultants came along with essentially the same recommendations:

1. Mistakes have to be caught EARLY in the process, when they can be corrected in a cost-effective manner, not LATE
2. Vehicle design and manufacturing have to be better engineered to reduce the incidence of errors introduced during assembly

In other words, testing is important, but good architecture is much more important. Without good architecture you are doomed to running a treadmill to keep the bugs out as the code is churned for feature development and maintenance.

Re:Hi, I'm In QA (0)

Anonymous Coward | about a year ago | (#42665329)

We do have a QA team, and they have the authority to approve/disapprove a release. The problem we've seen is that devs usually give the build too late to QA, and then QA is under pressure to complete their work in time, in which things get missed (manual QA). Our QA team is in the process of writing more extensive automated regression testing (which devs will also be able to run on any build themselves), which should reduce the issue of buggy releases. Our biggest problem in the dev-QA relationship is that dev frequently uses QA as an alternate for dev testing - which we want to avoid. We want to make sure dev doesn't completely offload the effort of fixing bugs in newly written code to QA.

However bad code may not have functional bugs in them. Bad code taking more CPU time (little latency impact right away, but adds up in the long term) or making the component difficult to maintain is something that QA can't help into.

I feel like we already had this conversation (0)

Anonymous Coward | about a year ago | (#42665035)

two times before.

GIve them a sense of ownership (5, Insightful)

brainstyle (752879) | about a year ago | (#42665043)

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.

Re:GIve them a sense of ownership (0)

Anonymous Coward | about a year ago | (#42665165)


Specifically I'd strongly recommend reading "Drive" by Dan Pink : http://www.danpink.com/books/drive

"Most of us believe that the best way to motivate ourselves and others is with external rewards like money—the carrot-and-stick approach. That’s a mistake, Daniel H. Pink says in, Drive: The Surprising Truth About What Motivates Us, his provocative and persuasive new book. The secret to high performance and satisfaction—at work, at school, and at home—is the deeply human need to direct our own lives, to learn and create new things, and to do better by ourselves and our world.

Drawing on four decades of scientific research on human motivation, Pink exposes the mismatch between what science knows and what business does—and how that affects every aspect of life. He demonstrates that while carrots and sticks worked successfully in the twentieth century, that’s precisely the wrong way to motivate people for today’s challenges. In Drive, he examines the three elements of true motivation—autonomy, mastery, and purpose—and offers smart and surprising techniques for putting these into action. Along the way, he takes us to companies that are enlisting new approaches to motivation and introduces us to the scientists and entrepreneurs who are pointing a bold way forward."

Re:GIve them a sense of ownership (0)

Anonymous Coward | about a year ago | (#42665447)

I agree this should ideally work. In our company, the biggest sense of ownership remains with the product guy, and the engineer is effectively acting as product fulfillment. How do you instill the sense of ownership into an engineer if the idea for the feature comes completely from outside engineering?

You must convince both management and developers (1)

bbbbryan (1089197) | about a year ago | (#42665063)

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.

Just like snipe hunting (4, Insightful)

narcc (412956) | about a year ago | (#42665075)

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.

Re:Just like snipe hunting (1)

codepunk (167897) | about a year ago | (#42665153)

This is one of those times when I wish I had mod points. "spot on my friend, spot on"

Re:Just like snipe hunting (5, Insightful)

engun (1234934) | about a year ago | (#42665293)

Your comment assumes that the person who criticises bad code is always a factory factory factory guy but fails to take into account that there IS such a thing as good code and bad code. The OP has outlined the reasons for why the code is bad - such as buggy releases, lack of test coverage etc. That indicates that the code or process is bad, somewhere.

Over-engineering is a problem yes, but just as commonly, under-engineering/non-engineering is an equally big problem. Both lead to bad code.

Re:Just like snipe hunting (0)

Anonymous Coward | about a year ago | (#42665365)

He's probably the factory factory factory guy AND he's probably the guy who introduces bugs all over the place, not knowingly of course.

abstract singleton factory method bridge prototype (2, Funny)

Anonymous Coward | about a year ago | (#42665479)

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!

Get management buy-in... (1)

mooingyak (720677) | about a year ago | (#42665091)

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.

Re:Get management buy-in... (0)

Anonymous Coward | about a year ago | (#42665387)

It's funny because it's true....

Re:Get management buy-in... (0)

Anonymous Coward | about a year ago | (#42665523)

This is something we are already do, and fail at. Engineers quote x days for writing unittests, say, but eventually don't and then product guys come knocking on the doors asking where is their release. I think the problem is that no unittesting is considered normal, so engineer doesn't face any penalty in this scenario - measurement is entirely based on if the product guy is happy. We are discussing how to change this.

My suggestion (2)

damn_registrars (1103043) | about a year ago | (#42665103)

Show them this lousy website [slashdot.org] 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.

you don't know what the goal is (1)

rubycodez (864176) | about a year ago | (#42665119)

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!

Seek employment elsewhere (1)

Anonymous Coward | about a year ago | (#42665127)

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.

BEER!!! (0)

Anonymous Coward | about a year ago | (#42665133)

Dude most stupidest question ever...

Start a new company, its the only way. (1)

j-stroy (640921) | about a year ago | (#42665137)

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.

Start small and do it in stages. (5, Informative)

ralphbecket (225429) | about a year ago | (#42665155)

(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.

Quit and work somewhere else (1)

cryfreedomlove (929828) | about a year ago | (#42665159)

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'.

Act on your own initiative, and beg forgiveness... (1)

Lodragandraoidh (639696) | about a year ago | (#42665161)

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.

Read "Code Complete", follow its guidelines (0)

Anonymous Coward | about a year ago | (#42665163)

Buy everyone a copy of the book "Code Complete". Give them a few days to read it, then have everyone agree to follow its guidelines. Done!


scrum and xp (0)

Anonymous Coward | about a year ago | (#42665167)

ask your question here...


and here...


captcha: moulding

Re:scrum and xp (0)

Anonymous Coward | about a year ago | (#42665435)

Are people really still doing XP? OMFG...

Do the following: (1)

Anonymous Coward | about a year ago | (#42665169)

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

Re:Do the following: (1)

c0lo (1497653) | about a year ago | (#42665407)

1. Write the worst code you possibly can.
(long list)

Used to be quite easy in the past. With C, you just needed let your pointer variables uninitialized or free twice the same memory.

Bribery and Punishment (4, Interesting)

vinn (4370) | about a year ago | (#42665175)

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.

Which part of the team you need to convince? (1)

c0lo (1497653) | about a year ago | (#42665193)

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.

The Politics (0)

Anonymous Coward | about a year ago | (#42665213)

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

Well let's see (1)

scamper_22 (1073470) | about a year ago | (#42665259)

"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.

Here, Let Me Try... (1)

Greyfox (87712) | about a year ago | (#42665277)

*ahem* Write better code or you're all fired! You have one month!

That ought to work.

Reading and writing... (0)

Anonymous Coward | about a year ago | (#42665287)

In programming, there's a lever... In one side you have: more time writing, in the other side you have: more time reading.
Code is written once, but read many, many fucking times.

If you ignore the importance of readable code, think in the following scenario: your product finally went live, and there's a bug. There is no fucking time to fix it. In that moment, you would like to look under the hood and see something that makes sense. Bad code will be hard to read, you will maintain it, and possibly introduce another bug, then another fix is issued, but another bug is introduced, and so on.

Write decent code. Challenge duct tape programmers, they poison your project and the industry.

Dollars & Sense (4, Insightful)

multimediavt (965608) | about a year ago | (#42665299)

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.

Management is not on board - You're fucked (1)

bigsexyjoe (581721) | about a year ago | (#42665301)

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.

Kill the "product guys" (1)

chriswaco (37809) | about a year ago | (#42665345)

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 (2)

Jane Q. Public (1010737) | about a year ago | (#42665373)

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".)

My Team has the Exact Same Problem (1)

Anonymous Coward | about a year ago | (#42665385)

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."

Be professional (1)

valentinas (2692229) | about a year ago | (#42665397)

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.

It starts at the top. (0)

Anonymous Coward | about a year ago | (#42665421)

The environment I'm working is a semi-military establishment with its top-level management ex-military former mainframers. And the situation there is that they have gone from having virtually no QC process in place to a water-fall model that allows the top managers to micro-manage the software development lifecycle at almost all stages, which they do.

Here are some further characteristics contributing to this malaise:

- Weak technical leadership, mid-level managers either have a very-out-of-date IT skill-set or do not have an IT background at all. This means that management is at a disadvantage when weighing technical solutions up front and going forward. This also usually leaves major technical decisions to the discretion of junior staff, who may not be sufficiently conversant with the technology they advocate (for example, recommend one solution that works fine for a small web-server with moderate traffic but does not at all scale up to large traffic environments), and this causes projects to fail.

- Lack of credibility with business section. Due to problems created by the previous reason, the business section, lacking faith in their IT deparment, then is tempted to (and in the place I am working actually does) dicate technology decisions to the IT department. The see some expensive tool or platform and then dictate to IT that they have to use it. IT having no choice in the matter purchases said snazzy tool/platform, runs into big problems cost overruns, and then gets further blamed for incompetency. A senior VP in the technology department was forced to retire because of a decision imposed on him by business that ran into cost overruns.

- Lack of incentive for developing skills in-house. The establishment I am at is using more and more commercial J2EE solutions, but they are unwilling to either train their current development teams in Java or hire people with J2EE experience. Even mid-level managers are complaining about this. In their words, top-management thinks if it can't be done on a mainframe, then it can't be done.

- The preceding points to a BLUE COLLAR CULTURE in the IT department fostered by management at top- and mid-levels. What is "blue collar" about the IT culture is that it is expected that little or no innovation is expected to take place in the course of developing solutions - even in new product development. Research and development is generally frowned upon as unnecessary.

- And when the blue-collar IT culture runs into reality, expensive contractors or contracting firms become a necessity, because you lack the inside technical expertise to implement new technologies. Hardware and software becomes obsolute and unsupported, and especially if a whole line of software or hardware becomes end-of-lifed, you had better be prepared to port your legacy apps to some new platform. New customers with lots of money and influence also have their own demands, which a stagnant IT department is ill prepared to accommodate.

And so the vicious cycle continues.

The problem is fundamentally one of who is in charge, and a distant second is who you hire. But mainly it is who is in charge, because they are the ones who hire or fire.

If the problem is fundamentally about who runs the show (and they have to have clout with other influential down-stream customers, like the business section or customers or board members), then start with your CIO or even your CEO. Yes, they will make most of the difference. They can start giving underperforming or toxic mid- and top-level managers "golden handshakes" and replace them with more competent people. Incentives can be put in place to improve staff. Hire better developers (if you are weak technically and are a manager, then hiring good people is more a function of luck than anything). And so forth.

So, the answer to your question (what can be done to change the culture) is very little. You can't do much at all from the bottom. Even if you are a mid-level manager there is not much you can do to change things. I've had them cry on my consultant shoulder about their own limitations.

That said, at your position, there is a lot you can do to sabotage plans moving forward. (But that is for some other Ask Slashdot feature.)

But in summary, the answer to your original question is that you can do next-to-nothing to change things.

It's going to be hard (1)

engun (1234934) | about a year ago | (#42665431)

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.

Schedules (1)

boundary (1226600) | about a year ago | (#42665441)

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.

Here's how you solve this one. (0)

cshark (673578) | about a year ago | (#42665451)

Just based on what you seem to be saying, it sounds like there are a number of issues. These issues are probably more social than they are technical. It also sounds like the team has little incentive to do the right thing, and that you more than likely have a clueless project manager (probably, but not necessarily a woman) who refuses to understand the technical aspects of whatever it is you're doing.

If the problem is poor management, you're going to need a better project manager. Someone with a history of delivering results in situations like this. Unfortunately, great project managers are so few and far between, that I can say with some certainty that it'll take you at least a year, possibly longer to find the right one.

If you're certain the issue is not the project management, take a look at the processes, and limit who has commit rights on the main cvs/subversion/git branch. In fact, you actually want to go so far as to give the keys to the main branch to one person who will be held accountable for the quality of the overall system. This way, nobody feels left out or punished. And everybody feels bad for the guy who can be fired for your fuck up... at least, until he starts pushing back on bad code.

Require all code to go through an approval and review process by this person before it can be committed to the main branch of your source repository. If necessary, tie this person into the quality assurance apparatus that you already have in place for your product. Sell it to this person as a "promotion," and pay him a couple grand more a year to do it. It's not going to kill the company, and it should be enough for this guy to take the job seriously.

Throw the word specialist, or manager in his title, and give him the the power to send code back when it needs to be fixed. Make no mistake... feelings of empathy for his plight won't last long, and he will be hated if he's part of Q/A, unless he's exceptionally charming. But do not flinch on him being the one and only person allowed to commit to main, come hell or high water. There will be objections, and they will most likely come from your worst offenders.

I know it sounds harsh. It's just that there aren't a lot of ways to fix a situation like this one. In my experience, this method is the least invasive of the options you have available, but it can be quickly derailed by bad or inappropriate project management or team governance. Be careful, see it through, and you'll be fine.

Frequent beatings (0)

Anonymous Coward | about a year ago | (#42665457)

until morale and performance improves

Small incremental change (1)

phantomfive (622387) | about a year ago | (#42665467)

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.

Take one for the team (0)

Anonymous Coward | about a year ago | (#42665507)

One of you has to take one for the team and become director of engineering.

Have an hour meeting every week (2)

lawpoop (604919) | about a year ago | (#42665515)

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.

Social Change? (0)

Anonymous Coward | about a year ago | (#42665535)

Why is social change the preferred method to convince anyone that your way is better? You will probably have more luck with facts and well formed arguments in favor of your approach.

Automated tests facilitate fast development (0)

Anonymous Coward | about a year ago | (#42665567)

Start showing how much faster you can get work done by building and maintaining your own test suite. Once they start to like the idea, they will ask that it becomes a fully automated system with full team focus. You won't need to convince them.

That is the main thing but the aforementioned "sense of ownership" is a great idea, too.

Wrong focus (1)

Dcnjoe60 (682885) | about a year ago | (#42665577)

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.

Appalling code (0)

Anonymous Coward | about a year ago | (#42665581)

You don't work for Oracle do you.

Get good programmers (0)

Anonymous Coward | about a year ago | (#42665613)

You say you have software changes with a lot of bugs, bad design and slow implementation. All these are signs that you have bad programmers. No amount of culture fixing and procedures can fix that problem. Identify your good programmers and make them do all the programming (If you have no good programmers , you will have to hire some). To the others assign support roles or let them surf the Internet all day if you cannot fire them. It is not that difficult to identify the good ones. They are the ones whose changes go in with few or no problems.

Nope (1)

russotto (537200) | about a year ago | (#42665657)

We feel that if the right thing is done every time, we would can eliminate our issues and still release at the same pace.

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account