Forgot your password?
typodupeerror
Programming

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

Posted by Soulskill
from the cattleprods-are-your-best-bet dept.
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?"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Sooo.. (Score:5, Funny)

    by kiriath (2670145) on Tuesday January 22, 2013 @11:14PM (#42664945)

    Do you work for Blizzard?

    • by nedwidek (98930)

      IBM. Definitely IBM.

      • by Taco Cowboy (5327) on Wednesday January 23, 2013 @12:51AM (#42665703) Journal

        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.

        • lack of ethics (Score:4, Insightful)

          by luis_a_espinal (1810296) on Wednesday January 23, 2013 @12:14PM (#42670127) Homepage

          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.

    • Re:Sooo.. (Score:5, Interesting)

      by phantomfive (622387) on Wednesday January 23, 2013 @12:20AM (#42665505) Journal
      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.
      • Re:Sooo.. (Score:4, Funny)

        by Anonymous Coward on Wednesday January 23, 2013 @01:32AM (#42665987)

        So.. you are saying good code equals company goes bust? Straps on flameproof suit and helmet...

        • So.. you are saying good code equals company goes bust?

          It's kind of worrisome, isn't it?

          • So.. you are saying good code equals company goes bust?

            It's kind of worrisome, isn't it?

            The perversity of the universe tends towards the maximum

            Larry Niven (I think).

        • by sjames (1099)

          In a sense. When a development staff are happy, working normal hours, and cranking out quality code, the management from newly minted MBAs on up to the CEO all have a single thought: "If I squeeze hard enough, I can get a few more nickles out of that department for my bonus check". So they decimate the workforce and rattle off platitudes like "work smarter, not harder" at an ever increasing rate. They set "stretch goals" but punish people severely for not meeting them. They demand shorter deadlines and more

      • Google's code that they have released seems pretty decent.

        • Re:Sooo.. (Score:5, Interesting)

          by phantomfive (622387) on Wednesday January 23, 2013 @02:01AM (#42666213) Journal

          Google's code that they have released seems pretty decent.

          I don't know which code you were looking at, you are probably right. But I can tell you, I've spent a lot of time in the Android codebase, and that thing is giant mess. Everywhere you look there are bugs. You can report them and they don't get fixed. There is undocumented behavior. More than once I've wanted to throw my monitor out the window in a rage after working on Google code. I hate their stuff.

        • That certainly isn't the case on any of the projects I've worked on with Google contributors. They tend to think a nest of #ifdefs is the correct way of writing cross-platform code, and fall into the trap of thinking that the solution to any problem - especially the problem that the current codebase is overcomplicated - is to add more code.
      • Re: (Score:3, Insightful)

        by dgatwood (11270)

        What companies do you know that produce good, high-quality code?

        Consistently or occasionally? From what I've seen, your average company produces one or two great products and a lot of half-assed projects. I call this the Lightroom-Flash spectrum. On the upper bound, you have code that is fairly well written (apart from that case-sensitivity maps bug, ahem...), and on the lower bound, you have... well, Flash.

        What distinguishes one from the other? IMO, you can roughly quantify it as: q = 1 / (t_sub_r * b_

      • Re:Sooo.. (Score:5, Informative)

        by invid (163714) on Wednesday January 23, 2013 @09:39AM (#42668395) Homepage
        I used to work for a company that produced avionics software. Obviously, we had to write solid code. This is how we did it: (1) Mandatory line by line code review by a different department. (2) Have a test cycle about as long as the development cycle. (3) Be willing to sacrifice the schedule to make it work. This is why planes are late and over-budget, but I wouldn't fly otherwise. And no, I had nothing to do with the 787.
        • I used to work for a company that produced avionics software. Obviously, we had to write solid code.

          The On-Board Shuttle group is (was) even more bad-ass than that. [fastcompany.com] For them, 5 9s (99.999% failure rate) was unacceptably lax.

          FTFA:

          But how much work the software does is not what makes it remarkable. What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider

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

        The small companies I've worked for have aimed to produce good code. The insurance company where I had my first professional programming job, we aimed to produce good code (and we methodically refactored badly written legacy code inherited from a contractor.)

        When I worked for Citircorp Latin America Division, I remember every development team aiming to have some quality in their deliverables. With other large companies, I've seen teams producing shitty code, but also teams having outstanding performance.

    • Re:Sooo.. (Score:4, Informative)

      by Big Hairy Ian (1155547) on Wednesday January 23, 2013 @10:05AM (#42668637)
      There are a number of things you could try.

      1. Pair programming usually improves coding standards

      2. Code Reviews can promote improved standards

      3. Don't let them maintain code they've worked on before unless it's been round the rest of the team

      HTH

      • by AuMatar (183847)

        I don't find constant pair programming improves standards. I find it slows development to a crawl while leading to developers who are either mentally checked out or goofing around most of the day. Or depending on your developers, arguing over inanities. Or they just leave- I wouldn't stay at a job where I was going to literally have someone standing over my shoulder telling me what to do all day.

        Code reviews are good, but you have the same problem as the OP does- you have to convince people not to half

  • Easy (Score:5, Funny)

    by Anonymous Coward on Tuesday January 22, 2013 @11:14PM (#42664947)

    1. Higher Pay
    2. Good Management
    3. Beatings

    Pick any two.

  • by Anonymous Coward on Tuesday January 22, 2013 @11:18PM (#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.

    • by NevarMore (248971) on Wednesday January 23, 2013 @12:00AM (#42665353) Homepage Journal

      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!

    • by Austerity Empowers (669817) on Wednesday January 23, 2013 @12:26AM (#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: (Score:3, Insightful)

      by Anonymous Coward

      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

  • You are doomed (Score:5, Insightful)

    by Stirling Newberry (848268) on Tuesday January 22, 2013 @11:19PM (#42664985) Homepage Journal
    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.
    • by gregor-e (136142)
      Culture flows from the top. So long as software quality is constrained by arbitrary sales deadlines, your problem will not go away. The only way out of this mess is for management to buy into the value of quality and to insist on it, over the screams of marketing and sales. It is also a function of your customers. In many industries, customers will be ticked off for a while if you ship their product late, but if you ship them a brick, they'll never forget. Perhaps you are 'blessed' with more forgiving
      • by Splab (574204)

        Not necessarily; had the same problems described by poster in former work place. We solved it by locking down commits, bug reports and had the database guys drive development.

        No development was allowed without a bug/feature request, no commits where allowed without a bug reference. Database guys made the calls since the company money where in their domain.

        In the beginning there was a bit of unrest, but the rest of the crew quickly realized it was actually really nice to know exactly what went where and why.

    • by bikin (1113139)
      How I wish the parent were wrong, but he is dead on the spot. Unfortunately, unless you can convince someone up the chain that quality matters, you are going to keep in state forever. Quality is not free, though the returns outweigh the costs. I can assume that the OP just gets a request get M features in N time, when it will certainly take 2N to create the features, and there is no way to either change M or N. So my advice is the same, just polish your resume.
  • by Anonymous Coward on Tuesday January 22, 2013 @11:21PM (#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...")

  • by eksith (2776419) on Tuesday January 22, 2013 @11:21PM (#42665007) Homepage

    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.

    • I agree but I think the presentation needs a lot of concrete examples of wasted money. Technical debt is very expensive but most managers don't really understand it and how it impacts their schedules, competitiveness, and the bottom line. All they know how to do is count features but they really need to understand software development more so they can make more informed decisions.

  • by bobstreo (1320787) on Tuesday January 22, 2013 @11:22PM (#42665013)

    to outsource your work to someone in India giving you time to peruse Reddit?

  • by alvinrod (889928) on Tuesday January 22, 2013 @11:23PM (#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.
  • Hi, I'm In QA (Score:5, Insightful)

    by cosm (1072588) <thecosm3@EEEgmail.com minus threevowels> on Tuesday January 22, 2013 @11:25PM (#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).

    Signed,
    Your Friendly Neighborhood QA Tester
    • 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.

      • 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 wr

    • by Ichijo (607641)

      And give the QA team enough authority to prevent buggy releases.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        No. Please god NO.

        QA is not the Release-Police and shouldn't _ever_ put themselves in the role. QA's role is to tell you that something _is_ a buggy piece of shit, that Devs have been too stressed, that planning didn't go into architecture, and that all the "Crunch" is going to come back and haunt twice over.

        QA can have the role of saying that something stinks, but should also be able to tell you _where_ and _what_ and in some cases _how_ it stinks.

        However, QA should not be able to say "We won't release t

    • QA (Score:4, Interesting)

      by DavidClarkeHR (2769805) <david DOT clarke AT hrgeneralist DOT ca> on Tuesday January 22, 2013 @11:41PM (#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 (Score:4, Interesting)

      by Anonymous Coward on Tuesday January 22, 2013 @11:42PM (#42665211)

      yfnqat,

      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.

    • by PCM2 (4486)

      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

      I worked for a company that had a QA team. Basically, the presence of the QA team was seen as confirmation that every engineering decision was right and correct. Never mind that nobody ever listened to what the QA team said. The fact that they were allowed to speak up at meetings was proof that everything we did had "passed QA."

  • by brainstyle (752879) on Tuesday January 22, 2013 @11:26PM (#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.
  • by narcc (412956) on Tuesday January 22, 2013 @11:30PM (#42665075) Journal

    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.

    • by codepunk (167897)

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

    • by engun (1234934) on Tuesday January 22, 2013 @11:52PM (#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.
      • by junglee_iitk (651040) on Wednesday January 23, 2013 @02:35AM (#42666407)

        GP is part of the problem. For people like him/her, it is not about good code or bad code, it is about 'my way or the highway'.

        Calling someone "factory factory factory guy" without any basis is how you get mod points on Slashdot without being correct. For all one knows the submitter might be exact opposite.

    • by Anonymous Coward

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

  • by damn_registrars (1103043) <damn.registrars@gmail.com> on Tuesday January 22, 2013 @11:32PM (#42665103) Homepage Journal
    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.
  • 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!

  • 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.
  • by ralphbecket (225429) on Tuesday January 22, 2013 @11:37PM (#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.

    • by coofercat (719737)

      (5) Longer time-scales (at least for a time)

      If you're being hot-housed, you get something that ostensibly works out the door, and "to hell with the unit tests". I someone told me "I need X in a week", I'd just hash together any old crap that essentially meets the requirements. If they told me "do it as quickly as you can, let me know when it's done", then I'd probably spend a bit more time planning it out so that I could make a better job of it, and be reporting my progress along the way.

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

  • by vinn (4370) on Tuesday January 22, 2013 @11:39PM (#42665175) Homepage Journal

    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.

  • 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

  • "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 chu

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

    That ought to work.

  • Dollars & Sense (Score:5, Insightful)

    by multimediavt (965608) on Tuesday January 22, 2013 @11:52PM (#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.
  • 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'

  • by Jane Q. Public (1010737) on Wednesday January 23, 2013 @12:02AM (#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".)
  • 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 eve
  • 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

  • Have you tried making sure they have access to great food and drinks?
  • by lawpoop (604919) on Wednesday January 23, 2013 @12:20AM (#42665515) Homepage Journal
    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.
  • 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

  • First prize is a Cadillac Eldorado
    Second prize is a set of steak knives
    Third prize is "you're fired [imdb.com]."
  • by russotto (537200)

    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

  • "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
  • I thought we went through all this a week or two back.

    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 techn

  • 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 enginee

  • 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

  • Culture (Score:5, Insightful)

    by EmperorOfCanada (1332175) on Wednesday January 23, 2013 @01:19AM (#42665893)
    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
  • 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.

  • by khchung (462899) on Wednesday January 23, 2013 @01:43AM (#42666093) Journal

    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.

  • by swillden (191260) <shawn-ds@willden.org> on Wednesday January 23, 2013 @01:53AM (#42666157) Homepage Journal

    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 [wikipedia.org] 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

  • 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 agreem

  • "...we would can..." - seems to be a bug right there.
  • by codeButcher (223668) on Wednesday January 23, 2013 @03:46AM (#42666743)

    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.

  • 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 tak

  • by magic maverick (2615475) on Wednesday January 23, 2013 @05:46AM (#42667217) Homepage Journal

    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 [joelonsoftware.com]:
    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 [joelonsoftware.com]:

    You could just leave, I suppose. But presumably, there's some reason you're stuck there. The stock options haven't quite vested, there's no better place to work in Podunk, or perhaps your boss is holding someone you love hostage. In any case, dealing with life on a bad team can be infuriating. But there are strategies for improving your team from the bottom, and I'd like to share a few of them.

    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 [joelonsoftware.com] explains that you need an independent Q&A team with real power, while Things You Should Never Do, Part I [joelonsoftware.com] says don't throw out code and rewrite from scratch and Incentive Pay Considered Harmful [joelonsoftware.com] 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.

"It is easier to fight for principles than to live up to them." -- Alfred Adler

Working...