Forgot your password?
typodupeerror
Programming Software

Is Process Killing the Software Industry? 460

Posted by timothy
from the about-those-tps-reports dept.
blackbearnh writes "We all know by now that Test Driven Development is a best practice. And so is having 100% of your code reviewed. And 70% unit test coverage. And keeping your CCN complexity numbers below 20. And doing pre-sprint grooming of stories. And a hundred other industry 'best practices' that in isolation seem like a great idea. But at the end of the day, how much time does it leave for developers to be innovative and creative? A piece on O'Reilly Radar argues that excessive process in software development is sucking the life out of passionate developers, all in the name of making sure that 'good code' gets written. 'The underlying feedback loop making this progressively worse is that passionate programmers write great code, but process kills passion. Disaffected programmers write poor code, and poor code makes management add more process in an attempt to "make" their programmers write good code. That just makes morale worse, and so on.'"
This discussion has been archived. No new comments can be posted.

Is Process Killing the Software Industry?

Comments Filter:
  • "Creative" (Score:5, Insightful)

    by Anonymous Coward on Wednesday May 11, 2011 @08:13AM (#36092244)

    If you want to go off and do your own thing, fine. Have at it.

    But don't expect to write code that keeps a 777 safely in the air. That is the type of scenario that we need discipline, not creativity.

    • Re:"Creative" (Score:5, Insightful)

      by Entrope (68843) on Wednesday May 11, 2011 @08:25AM (#36092346) Homepage

      This is dead on. Every software-developing business needs to decide its own process needs. Even if they are developing safety-critical code that has to pass rigorous certifications (FDA, DO-178B, etc), sane people do not order everything on the process menu. However, an organization does have to look at its market, its code base, its structure/culture, and its history to figure out what kinds of process it should use. Sure, having a defined process means developers spend less time throwing code at the wall, but the code they do throw usually sticks to the wall better and longer, and they usually feel good about that.

      If someone seriously and repeatedly complains that following the process kills their passion, it is due either to a failure of that analysis or them being in the wrong organization. As an software developer and occasional manager and/or process guy, I have seen both cases. I have also seen cases where having a defined process helps channel creativity. Good process tools help you focus on the right parts of the problem; for example, having a template for a design description that identifies particular subjects to focus on, and may suggest areas that have been rabbit-holes in the past.

      • Re:"Creative" (Score:5, Insightful)

        by heathen_01 (1191043) on Wednesday May 11, 2011 @08:55AM (#36092602)

        This is dead on. Every software-developing business needs to decide its own process needs.

        This is just another cargo cult problem. Managers, seeing that another company/team use process X on a successful project, decide to implement the same process for their team. However no process will make a difference if the developers have been directed to build the wrong solution in the first place, even if the code is 100% bug free.

        • Re:"Creative" (Score:5, Insightful)

          by Skapare (16644) on Wednesday May 11, 2011 @11:17AM (#36094244) Homepage

          And the certifications don't actually check any code, they just check that the processes chosen are the right ones, and can even miss if the processes don't get adhered to. Perfectly developed and certified software can still have a ton of bugs that will crash that 777 or shut off the heart monitor in a hospital.

          Less on process and more on coder competency would help. Pick the best coders and double their pay.

      • I've heard some horror stories of companies which, as you say, "order everything on the process menu".
        Everything has to be signed off on by 20 people who have no relationship to the project, integration networks that a guarded more closely than production networks and even trivial projects take years to production etc etc.

        I know it can be painful writing documents which you know nobody will ever read because the one thing the org I last worked at lacked it was a good documentation tracking system so people

      • Re:"Creative" (Score:5, Interesting)

        by RyuuzakiTetsuya (195424) <taikiNO@SPAMcox.net> on Wednesday May 11, 2011 @09:11AM (#36092780)

        My thoughts exactly.

        I worked basically in the skunkworks for an ISP's call center. We developed the CMS that handled all of our policy and procedure documentation, we developed neat tools that interacted with our IVR for outages, displayed coverage maps with said outage data, and various little tools here and there.

        When we started, we weren't bound by our IT department's change management process. As our tools grew and as their usefulness permeated our business, we started to get noticed and before we knew it, we were being held to the same standards for process as teams who developed tools like our CRM and our internal ticketing system.

        The whole point of our skunkworks was to be nimble, efficient, and effective on smaller projects those teams didn't have the ability to take on due to commitment to other projects. Yet, as IT's demands for compliance grew, all of our advantages went away. Soon, i found myself having to answer, "Why is late?" and invariably the answer would be, "Oh, it's held up by IT's Process. It'll be three weeks." Managers weren't happy. I REALLY wasn't happy and stressed and my user base wasn't happy either(Although my user base had a certain degree more sympathy than management did).

        It sucked the life and effectiveness out of our team.

        When layoff time came a month ago, on paper, we looked like were banging rocks together, and bunch of us were laid off, with those teams that didn't have the time or resources to build these tools in the first place having to absorb yet more work.

        (note: I didn't mind the particular IT policies, they made sense, but, I felt like a sense of scale was lost when it came to our projects. Oh well.)

        • Re:"Creative" (Score:5, Insightful)

          by Archangel Michael (180766) on Wednesday May 11, 2011 @11:01AM (#36093984) Journal

          Was gonna mod you up, but instead, it hit me. The problem isn't the process, it is where the process is engaged. And I think the Article and subsequent posts clearly indicate there is a time and place for process, but not everything needs to be stuck in a process.

          In your case, you and your team were building tools for your own use and were doing it the quick and agile way. Dirty code that got stuff done quickly. You bypassed the systemic processes that were in place because they just got in the way.

          The successful code base often starts out as UGLY spaghetti code, but eventually needs to be cleaned up.

          What needs happen is your skunkworks program should be autonomous from the normal process. Only when something you've created gets noticed does it move from the skunkworks over to the normal development channel. To accomplish this, you have to be willing to hand off your code to someone who is, more than likely, going to "ruin" it by running it through the process of getting it clean and neat.

          This way, you can still build fast efficient code that is messy and ugly, and the managment can get code that is functional, and everyone can work towards getting it all nice and pretty by process. Everyone wins.

          Just my thought

          • "In your case, you and your team were building tools for your own use and were doing it the quick and agile way. Dirty code that got stuff done quickly."

            This kind of thinking is exactly the problem. There is no reason "agile" code has to be "dirty" code. Studies have shown that it can be of as good or better quality than code done "the other way". But management resists that, because... they think like you: if they are not dictating the process, it isn't going to get done "right".

          • This is why things like "Google Labs" exist, in my opinion. Just imagine if every company had a formal "Labs" entity within IS/IT. The only problem is that being able to have a free-flowing anything goes R&D-type department (which is separate from your ordinary every-day "structured" or process-based type department) usually requires corporate support, a company of a certain size, enough people, or enough discipline to separate R&D time from planned/organized/structured time.

            I believe the core pur

      • Re: (Score:2, Interesting)

        The usual problem is bosses who either don't want you to follow a process, or they don't want to have to bother with the work that they would have to do.

        How many times have you been told to forget updating the documentation or specs (or worse, "what documentation?"), or you're told to "just make it work"?

        Or you've sat in a meeting during a review of the current project, and it's just a waste of time because it's like management is just filling up their buzzword bingo card by spouting various processes

      • Re:"Creative" (Score:5, Insightful)

        by Omnifarious (11933) * <eric-slash@nOSPaM.omnifarious.org> on Wednesday May 11, 2011 @09:28AM (#36092980) Homepage Journal

        I rated you up, but I notice that most people seem to be missing the most important part of your post.

        If someone seriously and repeatedly complains that following the process kills their passion, it is due either to a failure of that analysis or them being in the wrong organization. As an software developer and occasional manager and/or process guy, I have seen both cases. I have also seen cases where having a defined process helps channel creativity. Good process tools help you focus on the right parts of the problem; for example, having a template for a design description that identifies particular subjects to focus on, and may suggest areas that have been rabbit-holes in the past.

        I agree that software development can be 'over-processed'. And I think that management frequently decides to 'apply more process!' in lieu of actually carefully thinking through what would help. But usually, when developers complain about process and delivering things on time, I think "Oh, so you just want to slap that code in there without even really knowing if it works. Write code, compile, problem solved!". Good process is what keeps you on-track and disciplined to write quality software. Too much software in our industry is of extremely poor quality, and that's still the case. Developers should feel proud of writing software that works, not how much software they write.

        Most of the responses I see to your post seem to be of the "You're darn right, all that process just kills development!" variety. No talking about how to balance things for quality results or anything of that nature. I'm kind of disappointed.

        • Re:"Creative" (Score:4, Interesting)

          by Entrope (68843) on Wednesday May 11, 2011 @10:21AM (#36093522) Homepage

          I am disappointed too. I have lost count of the times that my coworkers (or direct reports) decided to skip documenting a design because of pressure to get the code done, only to have that come back and bite them (and the project manager who was applying the schedule pressure) later. Then there is one coworker who made commits to reindent and reformat every source file in a project -- mixing that with functional changes. Another coworker decided to write his own not-quite-XML parser.

          I probably annoy my coworkers occasionally with my insistence that we define and follow certain (usually minimal) processes. I know there are one or two people who hate our code review system. However, I have never advocated for a new process unless it was meant to fix a recurring problem and I thought it was close to the most efficient way we could mitigate the problem.

      • by radtea (464814)

        If someone seriously and repeatedly complains that following the process kills their passion, it is due either to a failure of that analysis or them being in the wrong organization

        This.

        People who blame process are like people who blame XML, or C++, or any other tool.

        The problem is not the tool. The problem is the stupidity of the people who insist on using it in inappropriate ways.

        Process is never the problem. Stupidity is the problem, which leads to inappropriate processes, poor metrics and bad management.

        People who complain that "process kills creativity" are just as stupid as people who implement inappropriate processes. Ironically, they lack the creativity to see how appropria

    • by realxmp (518717)

      But don't expect to write code that keeps a 777 safely in the air. That is the type of scenario that we need discipline, not creativity.

      Keeping any aircraft/metro/car safely in the air/on the rails/road does require a process yes (specification in Z etc), but it needs to be balanced with a certain degree of interest in your subjects that only comes from enthusiasm. In the real world no specification is 100% complete and there are often times when a coder has to make a judgement call and send a memo asking for clarification saying "This was unclear I did this, confirm it is correct" (blocking until you get an answer isn't usually an option

    • by Anrego (830717) *

      Obviously the amount of process is going to be proportional to the number of metric ass-tonnes of shit that hit the fan if something goes wrong, but I still think there is room to at least choose processes that don't overlap too much or interfere with each other. In the aerospace, defense and medical industries, it's all about more and more process to make everyone feel better (and produce better software and such..). Bug gets caught in one phase of testing.. add more process so it would have been caught ea

    • Re:"Creative" (Score:4, Insightful)

      by donscarletti (569232) on Wednesday May 11, 2011 @08:50AM (#36092550)

      If you want to go off and do your own thing, fine. Have at it.

      But don't expect to write code that keeps a 777 safely in the air. That is the type of scenario that we need discipline, not creativity.

      You need creativity to write something accurate, elegant and easily reviewed, tested and verified. You need discipline to actually do the review, testing and verification steps. Both are equally important if you want something solid and delivered on time.

    • by vlm (69642)

      That is the type of scenario that we need discipline, not creativity.

      Its a mistake to think discipline and creativity must be bipolar exclusive opposites. Anecdotes from all parts of that venn diagram claimed as "universals" are not really insightful, either. The best solution will maximize both within constraints and specs, assuming you have the discipline to provide any, and enforce them.

    • Please accept this comment in lieu of mod points, which I do not have at the moment.
    • by ZeroExistenZ (721849) on Wednesday May 11, 2011 @09:26AM (#36092954)

      But don't expect to write code that keeps a 777 safely in the air.

      He writes about creativity. You write about engineering.

      There are now a multi-tude of disciplines in software development, yet this isn't very well understood.

      I agree that the "management squeezing the life out of their dev-teams to make deadlines" with their charts, while devs are filling out sheets like monkeys to justify the space they take up, then it is absolutely a process that is killing.

      I remember a time filling out 3 timesheets for the same work, filling out a scrumlog, doing a scrum-board, sitting in meetings, linking my code-check-ins with my timesheet. Management could make pretty graphs, but I wrote 20% of the code I did before. And it didn't work. All this overhead work is also not "estimated into the planning", so pressure mounts, creativity and production lowers.

      Maybe the ad-hoc wont keep the 777 in the air, your papertrail and logs wont even get the software to be installed into your 777 and it'll never lift off. But it justified the bill presented for all the hypothetical work done (spent on filling in "justification files")

    • Right. And maybe 1% of developers out there write code that is that critical. *Maybe* 1%. Most are writing web sites or internal applications that have nowhere near that kind of criticality.

    • If you want to go off and do your own thing, fine. Have at it.

      But don't expect to write code that keeps a 777 safely in the air. That is the type of scenario that we need discipline, not creativity.

      I just finished an intensive course on Human Computer Interface (HCI) design. True, poor code can cause these things to happen - but so can poor design. In your example, we read a research paper where they discovered pilots use spacial location and position of analog instruments and components to gain information "at a glance", but with an all digital design they received information in purely numerical means and thus were unable to quickly process the information (in other words, the cognitive load of th

  • by AdmiralXyz (1378985) on Wednesday May 11, 2011 @08:14AM (#36092254)
    I'm all-too-aware of this issue and how quickly it sucks the life out of you and prevents anything from getting done, but at the same time obviously having no process doesn't lead to stellar code either. My question is, do any of you work in a place where you think you've struck the right balance? What are you doing?
    • Good issue tracking, short iterations, and daily stand-ups to discuss issues. Assign mentors to junior developers that you know need help, and have the mentors spot check the code. Let the more experienced developers choose the stack, define the interfaces, an create prototypes, and then hand those off as a template for other developers to follow.

    • by tripleevenfall (1990004) on Wednesday May 11, 2011 @08:23AM (#36092330)

      Where I used to work, (I posted elsewhere here why I left development), part of the problem is that the attitude was always "another small task won't hurt engineering". "Another step in this process is not a big deal"... until there are so many of these tips and checks that you aren't doing anything else but these microtasks.

      I think that most places have big problems going cheap on staff. They cheap out on testing staff. They cheap out on training for the support people. They cheap out on resources for environments. All of these things cause more weight to be placed on the developers.

      And it's all by design... develppers are replaceable, in many companies' view - more are churned out of college annually and they only have a 2-5 year lifespan on average. Rather than expand budgets to reflect what development really should cost, they simply treat developers as disposable resources on a burnout/replace cycle.

    • by vlm (69642)

      My question is, do any of you work in a place where you think you've struck the right balance? What are you doing?

      Think of the brilliance of the parental strategy of having once kid cut the cake and the other kid select the slice? The way that cuts down on squabbling about who got the bigger piece of the pie? Application of this principle to coding/coders vs testing/testers seems obvious... Doesn't it?

      An inherently self stabilizing and self balancing system always works better than one managers best (possibly misguided) attempt at neo-authoritarianism.

      Also for gods sakes make everyone in management read Fred Brooks

      • by Eivind (15695)

        Brooks - and also The Pragmatic Programmer.

        Agreed. Read both. Fire people who do not or can not understand it.

    • Budget (Score:5, Insightful)

      by mrops (927562) on Wednesday May 11, 2011 @09:14AM (#36092826)

      My problem with process has always been budget. Folks higher up budget on the basis of minimal process and expect full process. If you want 70% unit-test coverage, that is twice the time the code would have taken if you did not write unit test. Add 3 times the time if you want good integration tests to go with it.

      Unfortunately, this makes a project costly. The problem occurs if the PM then demands full process when the time is not accordingly budgeted for it.

      Release cycles also become long.

      • If you want 70% unit-test coverage, that is twice the time the code would have taken if you did not write unit test. Add 3 times the time if you want good integration tests to go with it.

        Serisouly if that is the case for you you must either be a genius (the unit tests are for nothing and don't ever reveal anything) or you do really a lot of stuff wrong.

        Having >80% code coverage ashould cost less than 10% of the developmen time.

        And having the unit tests should save over the whole team a lot of time as it

        • Re:Budget (Score:5, Interesting)

          by AuMatar (183847) on Wednesday May 11, 2011 @01:07PM (#36095844)

          80% code coverage costing less than 10% development time? Only if you're either ignoring all errors, or have massive try catch blocks that catch everything generically (which means your code coverage numbers are garbage- if you aren't testing each way of generating each type of error, you only have a fraction of that coverage).

          I'm not going to deny the usefulness of unit tests, but in my experience writing a good unit test suite takes 50-200% of the time to code the function, depending on the complexity of the code being tested.

  • 70% unit coverage? CCN complexity 20? Pre-sprint grooming of stories? This article is apparently not meant for a general geek audience. Can someone translate these terms into something that non-professional programmers can comprehend?

    • Re:Over my head (Score:5, Informative)

      by Derkec (463377) on Wednesday May 11, 2011 @08:24AM (#36092344)

      70% Unit Coverage:
              -- You've written code level tests that flex 70% of your code checking for regression failures.

      CCN:
              -- Technical term you can look up, but basically it's a measure of how many decision points are in a block of code. Less decision points is simpler. Too many and you may have something difficult to test and difficult for a programmer to understand. Higher complexity generally means more risk and a higher need for testing of various types.

      Presprint grooming:
              -- A "sprint" is a time block set aside for development. Usually 2-8 weeks. The goal is declare what you're going to get done in that time and not change the requirements during that time. Between sprints, you can change your processes, "groom" stories (tasks that describe things in a user experience way generally).

      Test driven dev:
              -- When writing a new feature, right a test for that feature first and you're close to done when the test passes and you haven't broken other tests.

    • by stewbee (1019450)
      "70% unit coverage" means that your production code before being integrated should have touched at least 70% of the code. The complexity number is related to how many branching statements there are in a single function/program. You can look up how they compute it, but it involves basic graph theory. I have no idea what "pre-sprint grooming" is though.
      • by Anrego (830717) *

        I have no idea what "pre-sprint grooming" is

        It's from the agile crowd. Basically the idea is you have periods where you do just dev.. and periods where you look at processes and make changes to your use cases and such. Sounds weird to me (if I find something wrong in week 1 of dev, I want to fix it now, not plow through and go back later) ... but my understanding of it is foggy and even the most messed up approaches can claim a success story _somewhere_.

    • Re: (Score:2, Redundant)

      by mevets (322601)

      70% - out of every X lines of code, 70% of them are actually executed in test. For example, code might contain something like:
      if (month == 12 && day == 25) {
      printf("Joyous Season of Light\n");
      }
      However, without cheating, this holiday greeting would be untested on most testing days.

      CCN - a way of expressing the logical complexity of program code to flag potential trouble spots. Google Cyclomatic Complexity

      pre-sprint grooming - google agile development.

      [imho]
      Cover

  • Yes. When you need to spend almost as much time learning how to and using the tools, processes, and configuration than actually producing code... then yes. And no it doesn't always help make better code. A lot of the time it takes time away from making code good.
    • Re: (Score:3, Insightful)

      by Anonymous Coward
      the problem is always the same:

      how can manager get bonus lowering staff costs?

      they get cheapo developers and throw the top notch methodologies at them in the hope those will make up for the devs inexperience and plain incompetence.

      that gives in turn a bad name at methodologies and tools, because cheapo devs cannot understand nor benefit fully from them. what use is a pmd output to a guy who's never got the difference between passing by reference and passing by value?

      and there are, lots of them. just check a
  • Get rid of management!

  • by Tribaal_ch (1192815) on Wednesday May 11, 2011 @08:17AM (#36092278)
    Karma be damned, this is relevant [programmin...fucker.com] to TFA:
    • by syousef (465911)

      I'm passionate about programming, but not enough to have sex with my mother. I guess I'll never be a programming motherfucker.

  • by tripleevenfall (1990004) on Wednesday May 11, 2011 @08:18AM (#36092286)

    This is why I left development. After 5 years working at a software company I found that only 10% of my time or so was spent writing new code, which is the only thing I really liked about the job. The rest of the time was spent in meetings, wading through red tape, reviewing others' code, doing maintenance on the (junkpile) legacy system, doing remedial training for the front-line tech support staff, and the 5 million small tasks that have nothing to do with why I went into the career field.

    • What did you switch too? i find myself doing pretty much the same thing (lots of non-coding compared to actual coding), yet i cant think of something else i'd really enjoy (and which would provide me with the same income)

      I'm not fed up enough to switch careers by a long shot, but those meetings do get a bit old..

      • I went to work for one of our clients, administering the system I used to do development for. The starting salary was a bit less, but negligible. The regular hours and good work environment more than made up for the small loss of income.

      • by mevets (322601) on Wednesday May 11, 2011 @08:50AM (#36092562)

        I used to deplore meetings; listening to some preening jackass and thinking about how far we were getting behind by this. It isn't just the time sitting in the room, but depending on how bad it was, focus could be lost for the rest of the day.

        Then I became freelance. Meetings took on a whole new significance. These jackasses paying my rate because I'm good at a few things; but rather than have me do those things, I'm sitting in a meeting, bored, but well paid.

        Look at your contractors in the next meeting; if they aren't in the scapegoat chair, they are the only happy ones in the room.

      • by Anrego (830717) * on Wednesday May 11, 2011 @08:59AM (#36092638)

        Maybe try a smaller company. Find a nice 5 to 7 person operation, bonus points if software isn't the main objective. When you are programmer 1 of 1, you find very little process, and what process there is, you define.

    • by vlm (69642)

      This is why I left development. After 5 years working at a software company I found that only 10% of my time or so was spent writing new code, which is the only thing I really liked about the job.

      Something I've never understood, even after being in the game for three decades this year, is the proprietary field demands the majority of your time be spent doing all manner of foolishness. In the open source field, the programmers pretty much program 100% of the time they're "working". And the market has shown that any serious OS project absolutely crushes any proprietary project in reliability, featureset, security, documentation (At least in the internet / google / blogs / mailing list era).

      Even the

    • by hitmark (640295)

      http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work.html [ted.com]

      There is also a mention somewhere that a core lib of Amiga os was written by one guy over 2 days in virtual isolation. He only had to get one design issue clarified with a superior during the process.

  • by Haedrian (1676506) on Wednesday May 11, 2011 @08:18AM (#36092292)

    On one hand, I can understand the creative process that goes into coding and the 'fun' you have in making it your thing.

    However if you're likely to have millions of people depending on your code, which will alwso be modified by other people, then you had better have a good process as well.

    I used to work at a company which required that pretty much all the important pieces of code have JUnit tests for them. Whenever someone else touches your code - which is bound to happen (I was modifying code which was written years ago - and the author wasn't employed anymore), it'll be a good thing if you know you haven't smashed anything.

    So there's a time and a place for everything. If its very important code, yes please, strictness. If its something small and silly, then go creative on it.

    • by w_dragon (1802458)
      Except all you actually know is that you haven't smashed anything in a manner they thought to test for. In my experience while unit tests do decrease obvious bugs, they also decrease real testing after developing a feature where the developer runs the feature a few times to verify it actually works.
  • by Hognoxious (631665) on Wednesday May 11, 2011 @08:19AM (#36092298) Homepage Journal

    I've worked on projects where they had procedures as thick as a phone book, and it was still possible to write crap code. In fact, due to the incompetence of the person who wrote them , they sometimes pushed you into writing bad code.

    On the other hand, some programmers produce good code, whether they're specifically ordered to or not.

  • by 140Mandak262Jamuna (970587) on Wednesday May 11, 2011 @08:21AM (#36092312) Journal
    People who are passionate about coding, rarely make it to the management cadres, partly by choice, partly because they lack the other skills needed to be managers. So the management is filled with folks from sales, marketing and mediocre programmers.

    I think may be the guru-disciple system of education practiced (allegedly) in ancient India might bear better fruits. Guru lead teams with disciples learning from them might turn out better quality code, but the system would be expensive in the short run and takes a while to take root. The quarterly bottom line obsessed corporate world is as far away from the system of stoic ascetic guru living in a hut in a jungle accepting princes as students romanticized in Indian mythology.

    • by tripleevenfall (1990004) on Wednesday May 11, 2011 @08:32AM (#36092414)

      There's a lot of truth to what you say. I am one of those. I think I was a "B" grade coder. Not a star, but adequate. I developed the skill, met deadlines and specs. It just wasn't my calling like it is for some.

      Frankly, I don't think it's bad to have somewhat mediocre programmers in your management structure. We understand at least a good chunk of what developers are doing, and when we don't you can explain it to us and get understanding. If I'm a McManager who used to be in HR and has never written code, I'm not going to understand your basic needs as an engineering team. You won't be able to explain to me why a certain architecture isn't workable. I understand you and what you need 80% of the time and I can go fight those battles and leave you to code.

      I think it's good to have mediocre programmers become managers if they have the management skills necessary (and aren't simply promoted because everyone else is irreplacable). Most of the time those skills are not common to the skillset of the best developers. It's better to have average developers become good managers than having good developers moved out of programming and into management, leaving only mediocre programmers writing mediocre code.

  • Process (Score:2, Interesting)

    by Anonymous Coward

    Only about 10% of programmers are "artistes" who create new things of beauty...process stifles those.

    80% of programmers come to work more-or-less on time, sit where they are assigned, work using the tools and processes given, and produce most of an organizations output. Process is beneficial to those, in that it makes their work useful in the overall "whole."

    10% of programmers should be fired before they do any more damage. A better HR process would help with those.

    • Re:Process (Score:4, Funny)

      by roman_mir (125474) on Wednesday May 11, 2011 @08:40AM (#36092474) Homepage Journal

      your comment is mostly wrong.

      Only about 2% of programmers in a large company actually do most of the real work.

      20% are good for chit chat.

      78% should be fired immediately.

      • Re:Process (Score:4, Interesting)

        by internerdj (1319281) on Wednesday May 11, 2011 @09:55AM (#36093222)
        I've come to understand this. When I go to my boss for a performance raise, he evaluates me based on me compared to everyone under him. It is my advantage to have the 78%. When he sees this and he says that we need to break the company policy on raises over x% so we keep this great employee, his boss evaluates his request based on my bosses perspective of best one out of 62 rather than one of 11. It is my advantage to have the 78%. Not to mention that bigger groups need bigger funding, so when I need something to do my job I'll have a bigger funding pool to draw from.
  • The first version needs to written with passion. You then throw it away, and write the second version seriously. Also, code for your next php-driven social-thingy must be written with passion. Code for the satellite, not so much.

    • by Entrope (68843)

      Don't confuse impetuosity with passion. I write code with non-trivial safety outcomes if it fails to do its job. I manage to do it with both process and passion. Sometimes I even surprise myself and have passion for the more tedious parts of the process, because I know they make the product better given a certain schedule: The systems I work on are complex, and even though I am a smart guy, I cannot keep all the details on all the systems and subsystems I have to work on in my head long enough to analyze

      • by dkleinsc (563838)

        Same here - I'm passionate about code reviews and unit tests. Seriously. Especially on the stuff I've written, but also for other people's code.

        Unit testing is fun if you approach it with the right attitude: I'm going to explore a system and see how it behaves. Each test is a representation of the question "What should happen if I do this? What actually happens when I do it?" The first question is the joy of creating functional specs and design. The second question is the joy of experimenting.

        I'm also passi

    • by rwv (1636355)

      Also, code for your next php-driven social-thingy must be written with passion. Code for the satellite, not so much.

      I want to write a php-driven social-satellite. Should I be formal about my passion?

      Or maybe I should switch from php to python.... import antigravity [xkcd.com]

  • Measuring Code (Score:4, Insightful)

    by rwv (1636355) on Wednesday May 11, 2011 @08:27AM (#36092366) Homepage Journal
    The main issue is that measuring whether code is good or not is impossible. I promise you that I can write code that has the prescribed level of unit testing and complexity that also doesn't work. Software reliability/dependability was a problem in the 1960s. It's still a problem today. No silver bullet, and all that.
  • by shic (309152) on Wednesday May 11, 2011 @08:28AM (#36092386)

    What really cripples things is when process is deemed a substitute for understanding the specifics of individual situations - where a one-size-fits-all-problems approach is adopted and imposed - usually by people who have no practical experience with the processes they espouse.

    If software development could be successfully reduced to a process, I'd have automated it. Where there's a considerable burden of process, either the process is inappropriate - or developing the software itself is inappropriate as it amounts merely to re-inventing the wheel... an exercise in task creation that benefits no-one.

    We should think of software development techniques and apply them judiciously - and the more techniques a developer masters, the wider their skill-set and the better they will adapt to new challenges. The critical question that needs to be asked is this: why is a technique being used and is it providing tangible benefits? If this question can't be adequately answered, everyone involved is wasting their time.

    • by gbjbaanb (229885)

      you got that right - I think most of these 'best practices' are more fashionable things rather than ways to achieve excellence.

      I've been writing software for some time, and I used to write code well before TDD was invented. My codeworked back then, so why would I need TDD now? Sometimes I think maybe its because the tools and development practices are geared towards that - we do a lot of fast-development methods whereas once upon a time we'd take time to do design and validation before getting stuck in. Tod

  • There is a balance between process and actually getting things done. Most companies never find it. The biggest problem I have is when this is used to audit progress on a task. For instance, I am a consultant for a company just starting to get out of startup mentality. There's been a push for more process and they've implemented their version of Agile. One of my first tasks was to write a script to dump data from Agile Zen so they could run reports on how fast developers are finishing stories.

    Fail #1: A

    • I completely agree. I've come to believe that Agile development is a fad invented by some marketing genius to get big loads of buck from gullible enterprises. While TDD might be useful for, say... a linux kernel module, there's very little use for it in your standard "make me a module which reports in detail our budget surplus and deficits" project.

      It's much more efficient to hire a small team of beta-testers available on-demand ("Jim wrote this new model, can you test it please?") than wasting hundreds of

  • by Uruk (4907) on Wednesday May 11, 2011 @08:32AM (#36092412)

    Passion isn't important. Cost and risk are important. The processes are put in place to (attempt) to minimize cost and risk associated with software development. Experience teaches us that cost and risk are very high when building software.

    When it's your money paying for the development effort, feel free to structure it so that you can chase your passion.

    I sympathize with the idea that this kind of bureaucracy can suck the life out of developers, but guys, this is work. If it were that fun, they wouldn't have to pay you to do it.

    • by Entrope (68843)

      People who have passion about what they are doing are usually much more productive than people who view the job as a way to get a paycheck. They also tend to want to stay longer, meaning the organization saves on replacement and retraining costs. There are also just wrong processes (of which "too much process" is a case) for an organization, so organizations need to do cost/benefit analyses on their processes.

      Other than that, I agree with you. Developers have three choices when they are faced with a proc

      • by jbengt (874751) on Wednesday May 11, 2011 @02:01PM (#36096682)

        People who have passion about what they are doing are usually much more productive than people who view the job as a way to get a paycheck.

        I work in engineering, not software, still, the last time I encountered a passionate IT employee, he got fired for taking long, passionate lunches at the hotel down the street with an electrical engineer and fixing their timesheets to cover up their absence.

        On a more serious note, you don't have to choose between passion and apathy. I'll take conscientiousness over passion any work day. Passion can at times be dangerous to objective thinking, partner relations, or a professional standard of care.

    • by Derkec (463377) on Wednesday May 11, 2011 @09:11AM (#36092768)

      I firmly disagree. Passion is key. People who don't give a damn and people who don't enjoy coding tend to write crap. We try to hire for passion and smarts (knowing both are hard to interview for).

      Passionate people given good processes and tools are ideal.

    • by LordLucless (582312) on Wednesday May 11, 2011 @09:22AM (#36092916)

      And if you kill the passion, your cost (of hiring new developers because you drove the old ones away) and risk (of losing corporate knowledge in process) increases. So you can say "my money, my rules" all you like, but actually, it's reality that dictates the rules. And reality says if you burden people under a weight of bureaucracy disproportionate to what that bureaucracy is intended to accomplish, they'll leave. And if they don't leave, they're probably afraid of not finding another job, indicating that they're not good enough at their job to be confident in their abilities.

      Like pretty much everything, it's a balancing act. You need to provide direction, or the goose is going to go wandering around the yard instead of laying its damn eggs, but if you stifle it too much, the thing's going to croak.

  • As more and more DRM "solutions" are deployed, and the DRM systems themselves get larger, more complex, and more expensive, I think you'll find it not far from the truth that: "Process killing" IS the Software Industry.
  • And most software is not written by one individual.

    As soon as you have an actual team writing software and as soon as there are others telling this team what they have to code, you need every bit of control you can get. There's no way around that and every anecdote "proving" you can get away with passion and good coders just proves that you can be lucky.

  • by Derkec (463377) on Wednesday May 11, 2011 @08:38AM (#36092452)

    This is really the key insight of most Agile methodologies. Development should own the process and change it to suit their needs during regular retrospectives. The team (not the whining individual) should be able to say, "You know what, I think we're not getting bang for our buck out of this many unit tests, let's shift to 50% coverage." As long as that same team is taking ownership of the regression failures and making an informed trade-off their comfortable with, all is well.

    If you get a good team together, you're going to get good code. You'll get better code if you empower them. Experienced and good teams will usually have a lot of these processes and tools in place because noticing things like high code complexity automagically alerts them to "bad smells" that can be examined and either accepted as necessary or invested in to address or test more thouroughly.

    Generally, I think development is most fun when you're on a new project and don't give a damn about breaking things. Then it's pure creation. But once an app is older and there's some weird code you're staring at you have to decide, "is this probably a bug, or is this a bug fix for some weird situation or platform?" That's when you wish that the guy having fun three years ago had written some damn tests.

    • by gbjbaanb (229885)

      That's when you wish that the guy having fun three years ago had written some damn tests.

      But today, the guy who writes the tests (and hopefully keeps them updated) is the same one who agrees with the "my code is its own documentation" principle and doesn't put a single comment in there. He won;t have written the design specification either, or the install guide so you still won't know how the damn things works.

      There's no silver bullet for doing things right, TDD isn't any different. Good devs can tell bad c

  • Like in everything else, from economics, to love life (whatever it means for different people), there needs to be competition in software development. This means performance based compensation, this also means getting rid of those, who cannot achieve.

    Developers should get goals in terms of business questions, then they should be let to do their own estimates and they should 'bid' on projects. There should be tracking of the success of different projects - from accuracy of estimate time and cost to number

  • Process isn't the problem, environment isn't the problem, language isn't the problem. The problem is that everyone looks to all of these things as the silver bullet that's going to "fix" software. Test driven development doesn't make good software any more than I-495 makes New York City. There is no silver bullet. [virtualschool.edu]

  • by dazedNconfuzed (154242) on Wednesday May 11, 2011 @08:50AM (#36092560)

    In most engineering disciplines, the process of actually building something is long, hard, expensive, and persistent. If the project is build a bridge, you spend a lot of time making sure the design is right; why? because the process of actually building the bridge takes months or years, costs many millions of dollars, and once built is not easily replaced. There is no room for error, so process is taken very seriously as a central part of ensuring timely cost-effective correctness.

    In software, the process of actually building something is instant, easy, free, and transient. Type "make all" and go get some coffee; find a bug? tweak a couple lines and do it again. This distorts the development process; "process" gets snubbed as a costly distracting annoyance instead of the means of assuring that what gets delivered is correct, because it's just so dang easy to fix and rebuild in seconds ... losing sight of the long-term cost of not doing it right the first time.

    • by Tridus (79566) on Wednesday May 11, 2011 @09:08AM (#36092736) Homepage

      A bridge is also a fixed, well-known thing. It's not going to change radically in design between when you start and when you finish building it.

      Software on the other hand is written for customers who themselves don't know what they want, in a market that is probably rapidly changing. It WILL change between the start and the end of the project in a lot of cases. Sometimes it changes because the customer changes their mind. Sometimes it changes because the market changes. Sometimes laws change. Sometimes the customers were just flat out wrong in everything they told you and the entire design is wrong as a reuslt.

      When you're dealing with that, process does just get in the way.

      • " It's not going to change radically in design between when you start and when you finish building it."

        not true.
        In the process things gt changed, but it's part of the process. This includes new features added while building.

        You don't see it becasue:
        A) engineers can attach real world costs to any change and need to get someone to sign off on the costs.

        B) You don't build bridges, so you don't see any development issues.

        Properly engineered code would mean when a change comes up, you say 'it will take this long, and cost this much'. PLease sign the document stating this. You make the sign off a requirement for the developer. Meaning they get fired or fined. This way you protect them and have someon to take responsibility.

        When you go to the customer and say, sure we can do this,. It will take 2 months and cost you 20K extra. they may rethink their 'minor' change.

        Since the industry doesn't have that, I do it in email. They few times someone tried to call me out, I just forwarded and email and said 'I told my manager it would take this much longer and cost this much more and he approved it.'
        While not a lot of legal protection there, it has worked.
        Right now I work with a bunch of civil engineers. They get all the same crap software developers do BUT they have legal requirements for sign off, and protection if someone is trying to build something that isn't structurally safe.

        When dealing with that, the process will help you because as you go you will have a base of knowledge about how long something takes and what it costs.

        If someone wants a , without changing in parameters you need to call them out. Have a process means you have factual backing you can document.

        They say that if software developers built house, civilization would fall when the first woodpecker should up.

        I wish that was true, because after the last house fell, we would fix it. Instead the industry just slogs through this miasma of low quality slap it together crap over and over again.

    • In software, the process of actually building something is instant, easy, free, and transient.

      Then you should not use processes designed around the assumption that building something is slow, difficult, and expensive (which is not to say that you should not have processes).

    • by geekoid (135745)

      except programs also take months, cost millions of dollars and aren't easily replaced.

      "In software, the process of actually building something is instant, easy, free, and transient"
      Yeah, if you're writing hello, world program.

  • i've seen supposedly passionate coding in practice. good people but it's almost impossible to work with them since they social outcasts.

    a software release turns into a 4 hour nightmare because everything worked on their dev laptop but in the real world it doesn't work and they have to figure it out. but they don't give you all the information and you have to wait on the phone at night while they tinker and fix it in production. meanwhile employees can't take customer trouble tickets.

    or the billing system ca

  • A wise elder at a defense contractor once told me that process was like cholesterol. You can't have none. But too much will kill you.

  • Are you finding the majority of your code is actually made up of unit tests?
    How can you be confident that your tested code is safe when delivered into the clients hands?

    Introducing Meta-Test(tm) - with this breakthrough in software engineering methodology your drones can increase their coverage numbers without writing a single extra line of application code!!!!

    Hurry! Don't miss your spot at our upcoming seminar where you will receive details on how to send your drones to our new training sessions that you c

  • And i love programmers how manage to encapsulate good ideas in a way that they are not harmful.

  • If you want to see what happens when you keep layering more process on to try and fix perceived problems, just take a look at how any bureaucracy makes decisions. Government is well known for doing things that don't make any sense in the real world, and the reason why is that our (I work for a government) decision making isn't based on reality. Or even decision making, for that matter. It's all based on following a process and doing whatever comes out at the end. With enough process and a process-focused gr

  • by syousef (465911) on Wednesday May 11, 2011 @09:05AM (#36092712) Journal

    The real problem is that methodologies are followed, taught and practiced like religion instead of science. A new buzzword or buzzphrase and a new way of doing things will never substitute for thinking through whether what you're doing is actually working to attain the goal you've set out. Unit tests for example are brilliant when the developer gets control and is honest about using them. This almost never happens in practice. In practice unit test coverage becomes some bureaucratic check box to tick. What's worse is that there are dozens of industry expert consultancies wanting to sell you their own particular brand of excrement which may have some merit but the way it's sold - as a fix all for everything - will never be anything but a pile of poo.

  • Depends on what the software is doing. If it's controlling my car or my mom's pacemaker I want the developers having a passion for making sure the code is 100% correct.

  • Too often "process" and tools are used as a substitute for competence. It's VERY easy to follow process and design patterns and use all the latest tools and end up with a brittle design & implementation. It's also easy to create a very similar design/implementation that's is robust and extensible and easy to maintain. And 90% of the people I've worked with over the last 10-12 years wouldn't be able to look at them and determine which is better (they'd most likely say the first is better if they were

  • The creativity should come from Designers now. Developers just implement the design. It is the Designers that need the passion, Developers don't have that role anymore.
  • by Foofoobar (318279) on Wednesday May 11, 2011 @09:20AM (#36092892)
    You can use mediocre programmers if you have (and enforce) good development process and train them in best practices. Being able to build code that is easy for the programmer to read (and others to read), separation of sql/html,css,js/ etc into their respective parts of the MVC/ORM pattern, consistent inline documentation, consistent comments on code checkins, etc., following the same rules for writing code (development docs)

    A good development process can alleviate many of the problems with having to do all that testing as you test because you have a bad development process wherein you are unable to easily have the developer look at his comments, his documentation and his clearly written code and go 'oh thats the issue'

    Not saying this will ELIMINATE the need for testing but this reduces the need for at least 30-50% of it if everyone is properly trained in a good development process and it is enforced.

Facts are stubborn, but statistics are more pliable.

Working...