Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

It's Not Developers Slowing Things Down, It's the Process 186

An anonymous reader writes: Software engineers understand the pace of writing code, but frequently managers don't. One line of code might take 1 minute, and another line of code might take 1 day. But generally, everything averages out, and hitting your goals is more a function of properly setting your goals than of coding quickly or slowly., a company than analyzes productivity, has published some data to back this up. The amount of time actually developing a feature was a small and relatively consistent portion of its lifetime as a work ticket. The massively variable part of the process is when "stakeholders are figuring out specs and prioritizing work." The top disrupting influences (as experienced devs will recognize) are unclear and changing requirements. Another big cause of slowdowns is interrupting development work on one task to work on a second one. The article encourages managers to let devs contribute to the process and say "No" if the specs are too vague. Is there anything you'd add to this list?
This discussion has been archived. No new comments can be posted.

It's Not Developers Slowing Things Down, It's the Process

Comments Filter:
  • Take managers out of the equation and work gets done. Pretty simple.
    • by skaag ( 206358 ) on Friday November 21, 2014 @12:55PM (#48434577) Homepage Journal

      This is not exactly accurate. It hinges greatly on the type of manager we're talking about.

      For example if the manager is very hands-on, goes into the details, produces proper mock-ups, flow diagrams, and everything is properly documented: This type of manager can actually accelerate the development process significantly since developers now know exactly what to do. But again, this manager has to really know what he's doing, and have some serious programming experience in his past.

      • by TrippTDF ( 513419 ) <(moc.liamg) (ta) (dnalih)> on Friday November 21, 2014 @12:59PM (#48434611)
        There is also the management of the manager: If the manager has too many products/projects on their plate they can't dedicate the time and focus to being that detail-oriented manager that gets things done. A good manager can turn into a bad one if they can't focus. That's where even higher-level management needs to set expectations and manage proper headcount.
        • by AchilleTalon ( 540925 ) on Friday November 21, 2014 @01:08PM (#48434727) Homepage

          That is a good one. Sometimes, managers are having too many projects to manage at once and are experiencing the exact same problem as lead developers. They have to switch context so often they lose completely the focus when time comes to a particular project.

          Usually, when a position post description mention: "must work well under pressure", "must be able to multi-task", "seeking for rockstar developer", etc; you can be sure you don't want to work there. It is symptomatic of a shop which operates without enough staff and on low budget expecting miracles to come out from the process.

          • by sjames ( 1099 ) on Friday November 21, 2014 @01:51PM (#48435201) Homepage Journal

            Especially funny. Rock Stars don't multi-task. They lock themselves away in a darkened office working on the currently interesting single problem until it is solved. Then they come out, decompress, and repeat.

            Part of why they have rock star performance is that they don't multi-task and don't sit through endless meetings re-hashing yesterday's meeting.

            • Rock star performance is achievable by anyone who gets to focus on just one thing at a time. It's also called being a prima donna, not a rock star.


              • by Gr8Apes ( 679165 )
                This is provably false. There are certain people, we'll call them rock stars, that you can stick in a room and they'll get a better solution out faster that addresses everything you need versus 100 lines of doesn't work for 20% of the cases code. Sometimes the rock stars do this to existing code with a 1 line mod. It's because they actually take the time to understand the problem and can visualize the system, instead of writing some boilerplate garbage cut and pasted from stackoverflow.
                • For these groups: middle management, "UX" design, human resources, and everyone at or above executive level...

                  They get their own building, with its own network. We''ll call it location "E." The network is in no way connected to the outside world. There is no mailroom, and no delivery access to the building. All vehicles in the parking lot are to be classic Pintos. The parking lot shall be liberally equipped with speed bumps.

                  Developers, Manufacturing and Shipping work in another building or complex. We'll ca

                • ...some boilerplate garbage cut and pasted from stackoverflow.

                  Is the text still available on Stackoverflow following the paste operation?

                  Then you meant "copied and pasted". Not quite the same thing. You should use the one that actually means what you apparently want to say.

              • Rock star performance is achievable by anyone who gets to focus on just one thing at a time. It's also called being a prima donna, not a rock star.


                Pri Madonna, a Pop star.

        • by NatasRevol ( 731260 ) on Friday November 21, 2014 @01:28PM (#48434947) Journal

          Yeah, my company does that.

          75 features to be implemented by the end of the quarter.

          2 weeks in, cut it down to 50

          1 month in, cut it down to 20.

          Actually deliver 12 features.

          Planning & prioritization are all over the place for the first month. And code freeze is 2 weeks into the second month.

          Every single quarter. Why don't the people expecting 75 features every quarter get fired?

          I'm just glad I'm not a developer here.

          • Re:Nope... Nailed It (Score:4, Interesting)

            by RabidReindeer ( 2625839 ) on Friday November 21, 2014 @03:24PM (#48435995)

            Couple of big shops in my town. Take one for example. They had a 2-year window for a very important project.

            Bought (expensive trendy tool) from (major software vendor). Spent 18 months drawing stick-figure diagrams with (expensive trendy tool). Realized they only had 6 months for implementation and panicked. Basically tossed the stick-figure diagrams because they had to drastically modify expectations to make it in 6 months of 100-hour programming weeks. Using contract laborers who didn't know the company and how it operated, because they'd taken a chain-saw to the ranks of the in-house experienced staff.

            I'm sure that they learned a valuable lession from that and will never do anything like that again. I'm also sure that pigs fly and cows routinely jump over the moon.

            • I'm sure that they learned a valuable lession from that and will never do anything like that again. I'm also sure that pigs fly and cows routinely jump over the moon.

              This is a good illustration of the folly of top-down "waterfall" methodology. Too much micro-planning in advance, no action.

              • I'm sure that they learned a valuable lession from that and will never do anything like that again. I'm also sure that pigs fly and cows routinely jump over the moon.

                This is a good illustration of the folly of top-down "waterfall" methodology. Too much micro-planning in advance, no action.

                Well, they also think that they're "agile". And have another expensive trendy tool to ensure it.

                • Well, they also think that they're "agile". And have another expensive trendy tool to ensure it.

                  But according to the description their methodology very clearly ISN'T "agile", whether they think so or not.

                  Agile isn't a tool, it's a method. And that method doesn't include eons of top-down planning, no matter what tools are used. But I may be preaching to the choir here.

          • Weird as it sounds, you might be able to count yourself lucky. At least this company described here is re-setting expectations in a drastic and somewhat realistic manner halfway through the quarterly debacle. Instead, the management could hold steady 75% of the way through, then squeeze the developers for 90 hour weeks for three months "because you all are behind, and we have to make good on commitments, even if late".
        • To my mind, the best managers set up conditions for their staff to succeed and defend them against higher-level managers. That's it. Managers should take care of head-count and hiring and meetings and all the other boring but apparently necessary stuff; they shouldn't be responsible for *any* analysis and design, let alone coding. Because all the "boring" stuff will eat up someone's time, and better the designated victim, I mean manager, than someone responsible for making progress.

          The *worst* managers,

      • This is not exactly accurate. It hinges greatly on the type of manager we're talking about.

        For example if the manager is very hands-on, goes into the details, produces proper mock-ups, flow diagrams, and everything is properly documented: This type of manager can actually accelerate the development process significantly since developers now know exactly what to do. But again, this manager has to really know what he's doing, and have some serious programming experience in his past.

        Do agree it depends on the type of manager; but they don't necessarily need to know the subject matter to be useful and accelerate the project; sometimes a technical manager an make things much worse.

        I had one that gave me a very broad goal - produce a GUI like X for the application. He was fairly hands off, and things got done. He knew his limits and relied on the people under him to overcome those limits.

        I had another that was techical, but tried to be hands off - that is, until things weren't going

      • That's a manager who manages down. Most managers manage up.

        In my ~15 years of experience "manage down" managers are hurting their career advancement prospects by helping the company deliver. It's one of those corporate blackholes. Normally if you take care of your house, you have a nicer house to live in. If you maintain your car, you save money and have a more reliable car for longer. But in the corporate world, investing in yourself is usually trouble.

        Not everywhere, but 3 out of my 4 employers.

        • But in the corporate world, investing in yourself is usually trouble.

          I worked at one company that wouldn't train workers since management was afraid that they would get certified and go work for a competitor. Never mind that most employees were training themselves, getting certified and leaving for a competitor anyway.

      • For example if the manager is very hands-on, goes into the details, produces proper mock-ups, flow diagrams, and everything is properly documented: This type of manager can actually accelerate the development process significantly since developers now know exactly what to do.

        With this type of manager, as a programmer, you have to write exactly what he wants, and it's completely demotivating: the programmers cannot take any initiative.

        A manager must be available.
        Instead of mock-ups, diagrams, etc..., he/she must be available when the devs need him/her when some "obvious" feature is not written in the specs, or when to validate this or that feature.
        If the manager is never available, because he/she spends his time detailing the process or spending time in meetings, his/her team wi

      • Vague specs are bad. But.. there is little I hate more than when they go the other route and try to fill in all the techical details. I've received a lot of specs that already included things like database schema complete with really bad table implementations and duplicated data all over the place.

      • As a dev myself, I'm absolutely fine working with vague specs. As long as my manager accepts a few iterations for fine tuning. And considering the time that is spent for planning the smallest of details, that may even be more productive.

        Just don't give vague specs and complain about not sticking to them exactly.

      • Actually, one of the best things the manager can do is shield the team from other managers, and support them when talking to others.

      • > For example if the manager is very hands-on, goes into the details, produces proper mock-ups, flow diagrams, and everything is properly documented

        Then I'm afraid that nothing will get done, because the "proper mockups" take so much time to develop and build that they literally lock up all management time and prevent the developers from being able to write even a single line of code that actually does anything not already hand-written by management.

    • by sjbe ( 173966 )

      Take managers out of the equation and work gets done. Pretty simple.

      Pity it will be the wrong work getting done. On the upside life is simple.

    • by tnk1 ( 899206 ) on Friday November 21, 2014 @01:04PM (#48434675)

      You don't want to take managers out of the equation. They're the only people keeping the other departments from running you over. You see that most clearly, ironically, when you have an incompetent manager and you get run over in spite of it.

      And a bad manager in this sense isn't the evil taskmaster, it is the guy who has no idea of his team's capabilities and taskload. He's also probably a little clueless about what is or is not possible, but in that sense, it's more of a feature of him making promises without talking to the rest of the team first. That manager goes to meetings and lets himself get cowed into submission when sales or marketing goes after him because he has no facts. Removing someone in that position just means that engineering is no longer even a speed bump to unrealistic goals.

      Saying "No" to business people is not a valid strategy. You'll just find yourself replaced. Saying, "yes, but you'd need to spend 2 million dollars on it" with proof is a valid strategy. You don't want to sit around and come up with that data, that's what the manager is supposed to do.

      I agree that indecisive managers and overwrought process is probably the top cause of problems with productivity. However, there are good managers and bad ones. It pays to understand the difference.

      • by Svartalf ( 2997 )

        The problem with that particular notion ("Yes, but you'd need to spend...") is that they're oftentimes NOT savvy enough to grok where you're coming from and they'll just hear the "yes" and make you try to jam 18+ months of dev effort into 6-8 months with the typical, classical, predictable failures, in spite of explanations why it just won't work with their notion. They hear "yes" followed by "wah...wah-wah...wah-wah-wah" like on Peanuts animated features when the adults talked. The "yes" means to them

        • by Svartalf ( 2997 )

          And, if you've not figured out what I'm trying to tell you, my answer in your example would be, "Unless you want to spend two more million and spend 12 more months in development, and COMMIT to that- no."

          The idiot notion of not being "negative" is fantasy that some crazy HR people came up with to whitewash over the real problems going on in a given company. You need to not just simply say, "no", but in the same vein, trying to not say no is stupid, crazy, etc. Sometimes things ***ARE*** really negativ

          • by tnk1 ( 899206 )

            Of course, there is a time and a place for saying "No". However, there needs to be an understanding that engineers are there to make things happen. Business people aren't trying to get developers to do things because it amuses them to do so. So, there needs to be an understanding that while there are times to put your foot down, it is far, far better to be able to explain the level of effort required to achieve that goal and give some alternatives.

            You want to be in a position where you get them to say, "

      • by tlhIngan ( 30335 )

        And let's not forget another role of manager - managing the customer.

        Unless you want to dress up in a suit and tie because the customer expects it (some do) and babysit them for the week they're here and interface with them, those are tasks best left to the manager.

        Dealing with customers is a huge part of being a manager because customers can become extremely demanding especially if they're doing site visits and need to be babysat. Best to have someone else being interrupted every 5 minutes than you trying

        • But IT doesn't do that, so IT doesn't see that, so IT doesn't believe it exists, is part of a job or is important. IT is just as myopic as any other group of business people, they just think they have all the answers - just like every other group of business people.
    • Re:Nope... Nailed It (Score:4, Interesting)

      by OzPeter ( 195038 ) on Friday November 21, 2014 @01:05PM (#48434687)

      Take managers out of the equation and work gets done. Pretty simple.

      Yes, but what work gets done?

      Is it the sexy feature that the dev has been just dying to implement since he/she read about some new language/process/data type de jour?

      Or is it fixing the hard to locate bug in deep in the back end that deletes all the users data on seemingly random occurrences (and can be brushed off in dev's opinion as merely an aberration)

      • by bouldin ( 828821 )

        Or is it fixing the hard to locate bug in deep in the back end that deletes all the users data on seemingly random occurrences (and can be brushed off in dev's opinion as merely an aberration)

        I completely agree with your point, but would like to observe that senior or mid-level management always cares the LEAST about fixing old, broken stuff.

        Every place I've worked has had serious ghosts in the closet, but projects to go clean up old messes never get approved. This has been true across business, IT, and de

        • My experience has been that managers care a *great* deal about users (read clients) calling in and complaining that their data is gone and threaten to sue.
          Then again, I mostly worked in banking where reducing risk was a prominent concern for all parties.

    • Actually, this is all stuff known to project managers.

      When a project is initiated, the Project Manager first creates a Project Charter. This is done by identifying stakeholders (people doing the work, people affected by the work, people receiving deliverables... any individual or group who affects, is affected by, or perceives itself to be affected by any activity or outcome of the project) and gathering preliminary project requirements. Essentially, the project manager talks to the stakeholders to roug

      • by gtall ( 79522 ) on Friday November 21, 2014 @01:18PM (#48434817)

        That's nice, you left out architecture. Who's doing the overall architecture? Has it been done before? If it is new, better spend a lot of time doing the architecture. Unless....

        You have caught Agilitis. In this case, spend no time doing the architecture up front, do it on the fly. Add time to every single task you think you see for doing architecture related stuff. At the end, allocate a large blob of time to figure out the correct architecture rather than the one you built which now resembles a dirty snowball. And begin rebuilding the thing, reusing any errant parts you did in pass one. And because you are agile, be sure to appropriate time for execs who understand agile as they get to change what's necessary on the taste of their coffee that day, whether their secretary gave them a perky Good Morning, or whether their hair will turn sufficiently silver in time for that next promotion.

        • by Maxwell ( 13985 )

          Your argument is nonsense and can be extended to: he didn't even mention the servers, be sure to add a few megs of RAM for each feature to developed, and some HDD space too. Oh, and increase the chip speed for each new feature as well! Then later but new servers to replace the cobbled together disasters you built on the fly.

          We use Agile for the *development* process which is distinct from the *design* process. That is, we do architecture up front, including DB design, and - surprise - we even build the serv

          • by Bengie ( 1121981 ) on Friday November 21, 2014 @02:24PM (#48435479)

            We use Agile for the *development* process which is distinct from the *design* process. That is, we do architecture up front, including DB design, and - surprise - we even build the server platforms too!

            Don't ever leave your job unless this is becomes no longer true. So many people think agile is free tick to skip design and when wonder why agile isn't saving them from creating a pile of crap.

          • by AuMatar ( 183847 )

            Maybe you guys do, in which case it will probably work out fairly well. Most places use Agile for design and development- in fact Agilistas will claim that any time spent on design is wasted, and that one of the benefits of agile is not needing to do design, that a design will form as you go naturally. It tends to turn things into a major cluster fuck.

            • Not every Agile process recommends that kind of approach. I teach Agile development, and I certainly don't. When you see a lot of final year student projects, you see all sorts of interpretations of "Agile" methodology, from utter adhockery to an approach that's waterfall in all but name. The more successful students, and successful projects, will take the time to carefully design the parts of the system which are a) high-risk, and b) difficult to change, and don't bother with trivial design for simple,
    • by nine-times ( 778537 ) <> on Friday November 21, 2014 @01:11PM (#48434751) Homepage

      First, that doesn't seem to be what the article is saying. Second, I don't really believe that it's true.

      When I say "don't believe that it's true", I'm saying, "I don't believe that the removal of managers necessarily gets work done faster." I'm not talking about programming specifically-- I'm not a programmer, and managing programmers is not my expertise-- by my general experience is that a lot of people think managers are just wasting everyone's time, when the reality is more that most people don't understand what managers do. Unfortunately, this sometimes includes managers.

      A good manager often spends his day trying to figure out how to remove obstacles so that the people he's managing can just do their jobs. For example, the summary says, "The article encourages managers to let devs contribute to the process and say 'No' if the specs are too vague." That sounds right to me. First, a good manager will of course listen to the people he's managing. That doesn't mean doing whatever they say, but when I have managed programmers, I assume that they know what they're doing better than I do, so if they say there's a problem of some sort, there's a problem of some sort. I wouldn't always go with their recommended solution, but would I listen to their explanation of the problem and try to come to a solution that addressed the programmers complaint as well as meeting the business needs we were trying to address.

      If specs are too vague, that seems like the sort of thing a good manager would help to work out. For example, I might suggest talking to the programmer, trying to figure out which aspect of the specs are too vague, and then meeting with the stakeholders to try to clarify the specs. I wouldn't necessarily make the developer get involved in the process of clarifying them, since unless they're needed for the discussion, they probably have better things to do.

      But being a good manager is pretty difficult in general. It's often not clear what needs to be done, or how it ought to be done, and it's your job to figure that out. It's pretty much impossible to be a bad manager without annoying people, but even the best managers might seem annoying or clueless because you don't see what they're doing for you. Sometimes good managers are only noticeable in their absence-- when they go away, you suddenly go "Oh jeeze, things are falling apart a bit here. How was it that we never had these problems before?" And the answer is, you were having those problems, but your manager was dealing with them when you weren't paying attention.

    • by SQLGuru ( 980662 )

      Turn around.....the congregation is over there. This is the choir. But preach on.

    • My manager never gets involved into the development process except when there's an escalation, usually from me. He's there to help me overcome hurdles, nothing more. And he's been really good at keeping stupid people at bay.

    • by Stripe7 ( 571267 )
      Managers are supposed to manage the time of their charges. Document everything, if there is a ticket, document the ticket and every change to that ticket. If they keep changing/moving the target document every change. If you spend more time documenting the changes than actually doing the task, then you know you will never complete the task as whatever code you write will be obsolete before you even finish start to code. Documenting the changes requested is your best defense,
    • If "working on your tan" counts as work, sure.

    • : )

    • This is a quote from Elon Musk on what he thinks [] about "process":

      "I don't believe in process. In fact, when I interview a potential employee and he or she says that 'it's all about the process,' I see that as a bad sign.

      "The problem is that at a lot of big companies, process becomes a substitute for thinking. You're encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren't that smart, who aren't that creative."

      This just about nails it for me.

      • Absolutely. Wasn't it the Bard who said, The first thing we do, let's kill all the process junkies!?

        Or, in this more enlightened era, maybe we can send them out to work on a farm for awhile--the fresh air, sunshine, and exercise would do them a world of good, and they'd at long last get the chance to learn a useful trade. Not to mention the most excellent poetic justice factor when they're the ones shovelling the horseshit...

    • I played a funny card game once where the engineers would work on projects indefinitely until you got a release manager card to make sure stuff really ships.

  • I insist on the right to refuse any tickets from the moron in sales who never makes a fresh pot of coffee when it's out.

    Don't mess with my programming fuel!

  • Please pick up any courtesy phone in the lobby and read out any and all relevant chapters.

  • When I worked as a lead video game tester at Accolade/Infogrames/Atari (same company, different owners, multiple personality disorder), my schedule estimate for code release was always accurate (+/- two weeks). Unlike the developers and producer, I didn't get a completion bonus for hitting the milestone dates. Their bonuses would fly out the window because they spent so much time trying to hit milestone date that the game couldn't pass QA. Not my fault that they can't code in a timely fashion.
    • by gnupun ( 752725 )

      Not my fault that they can't code in a timely fashion.

      This statement always make me laugh. How can you plan how long something will take if it has never been done before? You can't, and in the case of software it has not been done before. The managers are applying the same planning process that is used in less creative processes like road-building, bridge-building, building construction etc., where each task has already been done for decades or hundreds of years so you know how long some task will take.

      • The marketing department are applying the same planning process...


      • If the task in front of you is so revolutionary that it has never been done before, then you really are building a prototype. This belongs in the realm of R&D which has its own theories and methodologies for handling project scheduling. However, most software projects are built using a set of known technologies. If you properly decompose your system design, an experienced developer should be able to estimate the amount of time required to code each part with a reasonable margin of error. So you are

        • Programming is not construction. Programming is design. It's always going to be fuzzier than actual production.

          Manufacturing, in software, is trivial. This apparently leads people to think that software development is something like manufacturing, because they want a visible step there.

    • In that sense, I think it's also about setting realistic expectations. With almost anything you want to do, there's some limit to how fast it can be done, even with unlimited resources. Limiting the resources available below the optimal level will increase the amount of time to accomplish things. So you can't take a project that will take 6 months to complete, cut the resources to keep the budget low, and then set a project schedule for 3 months and expect it to work.

      After a certain point, providing big

  • Sure, people at all levels should be encouraged to say "no" if other things are wrong too; for example choice of architecture, data model, choice of development environment, language or database...

    Unfortunately, I've seen too many projects where people - including me - said "no" very loudly on these and similar issues and...were ignored.

    Hilarity ensued.

  • by quietwalker ( 969769 ) <> on Friday November 21, 2014 @01:12PM (#48434755)

    On time completion: It will be done as soon as it can be done, only experienced teams can provide reasonable estimates, developers provide timetables not managers, there's a specific amount of work that must be done before release and putting dates on it won't reduce the total amount of work that needs to be done.

    Unclear requirements: It's now the developer's job to talk to the stakeholders and find out what all the requirements are at the point in time they need to size or implement them. They get a vague 'story' that gives an overall concept of a requirement, and then it's up to the dev to talk to whomever needs talking to, then.

    Changing requirements: This happens and everyone expects it. So you do only the least work required to complete each requirement so the overhead in a change will be the smallest, and then you just pop that item on the queue and it gets done, that's it.

    Context switching: Tasks are assigned to a team by managers, not as a sole developer, so if context switching is causing a problem, it's up to the team to figure out how to minimize it.

    Take responsibility: They are, and increasing the duties that a developer has, while removing certain responsibilities from managers and product owners, which more accurately represents the reality of the situation.

    Caveat: Recent studies have shown that Agile is not as good as a waterfall-agile mix, where you do a good amount of planning (especially architectural planning) prior to the agile-like development, which makes a lot of sense. If half your work effort is refactoring, at some point you start take a severe hit to either efficiency, quality (robustness, maintainability, operational limits like memory or speed, etc), or time.

    • Re: (Score:2, Informative)

      by JohnFen ( 1641097 )

      Yes, those are the ideals of agile. But I have never seen any of them successfully done in the real world. Instead agile as implemented (which never resembles the ideal) just makes everything worse.

    • by FrnkMit ( 302934 ) on Friday November 21, 2014 @02:50PM (#48435725) Homepage

      It depends which parts are "agile" and which are "waterfall". From my not-exactly-vast experience, whatever mix you choose has to address four concerns:

      1. WHAT ARE YOU BUILDING? Seriously. This is where the extra planning of "waterfall" -- itself a misunderstanding of someone else's comments -- comes in. One of my first jobs was a derivatives trading app in a perpetual tug of war between an outspoken exotic derivatives trader, back office and compliance folks wanting to automate trade reconciliation, risk managers wanting to manage risk, and the rest of the trading desk who just wanted to price whatever deal they were trying to do (vanilla or not). The end result was a kludgey mess that everyone hated.

      2. HOW DO YOU ALLOW FOR GROWTH? There are right ways and wrong ways. Agile has a good tip: build only what you need, and as cleanly as you can. Better said than done, of course, and sometimes (as the Pragmatic Programmers have said) you *know* there will be a database in there sooner or later, so plan your architecture accordingly even if it's a little awkward short-term. Then there's the wrong way, which I saw in one project: build a "flexible" architecture with "configurable" components so that you can do "anything"! 1) KNOW WHAT YOU'RE BUILDING, even in broad strokes (see above). 2) For software to be reusable, it must first be usable for *something*. 3) If your "flexible" and "configurable" architecture takes more time to modify than writing straightforward code would take, it has failed; start over. 4) It's better to use open-source architecture than build it yourself. (Buying is also better, but beware of vendor lock-in and every-increasing fees, especially if you only use a small part of an elaborate framework.)

      3. HOW DO STAKE-HOLDERS REQUEST CHANGES? No specification will be adequate out of the gate, and unless you're working for NASA or the military people CAN and WILL request changes, sometimes while you're building the product and certainly once people begin using it. Do you jump when they say how high? Do you have a long and slow review process? Do you work individual tickets? Do you have potentially disruptive "projects", and if so how do you integrate them back into the main project? Different applications have different rates of change and different tolerance for defects, but it's best to work out change process before the complaints come in.

      4. WHEN AND HOW DO YOU CUT YOUR LOSSES? Despite your best efforts the whole thing will become obsolete or unmaintainable, sooner or later (hopefully later). As in point #1, have some idea which you're building, and at what point do you deprecate it to build something better. (This is the hardest part for many organizations; why can't the floor wax also be a salad dressing?) At some point make a plan, refactor your code base -- over time! -- to separate the parts you'll keep from the parts you don't need, and toss out the latter. If a radical rewrite is the only way to go, bite the bullet and do it, with appropriate safe-guards like regression tests. If you can't evolve or replace your product, a competitor -- maybe within your own organization -- will do it for you.

      That's my long-winded advice, from someone who's watched many "successful" and "unsuccessful" projects die. Nearly all in-house software is a Potemkin village designed to keep the tzars happy. If the tzars aren't happy, the fake village is set ablaze and you, the fake peasants, go to Siberia. The only real question is how to keep your frantic peasant dance going as long as possible without dying of exhaustion or being sent to Siberia.

      TL;DR: Plan the limits, goals, requirements, and large-scale architecture up front (erroneously called "waterfall"). But planning never really ends; stay agile to correct your course or take advantage of opportunities ... and be willing to throw the whole thing away if warranted. Also, keep your resume updated.

  • I'm surprised knowledge is not listed on there.

    I guess it depends on what you work on. But in many places I've worked, you are interacting with other pieces of software both old and new. Often times interacting with these is a bit of a void and you end up having to figure it all out, which is error prone.

    Knowledge maintenance is not something that is accounted for in the process. Heck, you could probably even get accounting on board with that one.

    The other part of it is a lack of devops.

    A big part of the bl

  • Generally it takes about the same amount of time to actually write Good Code as it does to actually write Bad Code.

    The differences are more along the lines of:

    1) You often don't know code is bad - or how to write good code - until after you have done the work once. So effectively it can take twice as long to write the good code - once to write it badly, then again to write it well.

    2) Good code usually requires a good working environment. You can never write good code while your boss is demanding you h

  • Quit RIDING MY ASS, Jim!

  • by mark-t ( 151149 ) <> on Friday November 21, 2014 @01:30PM (#48434971) Journal

    ... when developers say "no", they soon find themselves unemployed.

    Of course, one could theoretically argue that working for an employer who won't give due consideration to a developer's input isn't worth working for in the first place, but that nice little theory doesn't pay the rent. Oh, and try explaining to a future would-be employer about why your last job didn't work out... care take a guess how that will go down?

    Of course, it might seem that working for yourself solves much of this problem, but even that still requires that you actually have paying clients, enough of them that you can support yourself on what they are willing to pay you. Of course, then you are actually back where you started, where saying "no" to a person who pays you money to do whatever it is that you do carries a risk of not getting paid by that person again. If you have enough clients, this may not be a problem to lose the odd one or two because they are dillholes, but getting to that point will take time... possibly many years... so until that time comes, you'll just have to do whatever the heck the person who is paying your salary tells you, unless you really have an affinity for living in a cardboard box on the street.

    • by PRMan ( 959735 )
      That's OK. There's 500 other companies where I live that are all looking for 5 more developers. So no big...
    • by iamacat ( 583406 )

      Seems like a horrible and unusual experience. In a sane organization, getting fired would be a very extreme response to not participating in a single project. You will likely be transferred to something more to your liking. If it's your constant attitude, then yes you will have problems. But then how do you expect to work in a place if you can not make yourself useful?

    • by Bengie ( 1121981 )
      As a developer, a good portion of what I do is consult my manager. I'd say it's about 50/50 in that I tell him how it should be done, and I get my way, or I do exactly what he says, or some general mix of the two.

      If all they want you to do is code, then they want a code monkey, not a programmer. There may be a lack of jobs where you are, but I'd look around for better.
    • by Matheus ( 586080 )

      That's why you don't really say "No".

      Assuming your boss isn't asking you to do something unethical or illegal, your job is to provide as much information so the best possible decision can be made. SO in this case you will be telling your boss (customer/$$$/etc) everything wrong with what they are telling you to do. If after all of that their decision doesn't agree with your data then it is their liability. You did your due diligence and should document it thoroughly and documentation means you're getting

  • Expensive consultants have released a shocking report demonstrating that water is wet.
  • The article encourages managers to let devs contribute to the process and say "No" if the specs are too vague.

    Well, I hate getting into a process too early and I hate getting into a process too late. Too early and they still haven't agreed on what it is they want, why they want it and you end up wasting time listening to a whole lot of arguing and proposals back and forth that have nothing to do with the technical feasibility of any solution. It's like having the chef waiting while the guests are debating fish vs steak vs chicken, they're all good dishes so pick the one you want. It's another thing if they're looki

  • The last thing you want to do is quickly release an application that people do not understand and that doesn't do what is needed. A delay in release is much preferable. Multiple prototypes and user studies may be needed to clarify those vague specs.

    Yes, discipline is needed and indecision can be taken to extremes. But most apps/services fail because they have not been adequately thought through rather than by launching late.

  • Don't hate the player, hate the game.

    Trouble is, the game never changes.

  • Get the meetings in check.

    A good manager can isolate devs from most meetings and will efficiently communicate what needs communicated. Unavoidable meetings should be scheduled for as short a span as possible and must end on time, no exceptions.
    • by Gramie2 ( 411713 )
      Absolutely. I have 2-3 meetings a week, almost never lasting more than one hour each. My boss shields me from all the other crap that I would otherwise have to deal with, including saying "NO", which I'm not very good at.
  • ... regarding feedback, see bret Victor on this. Computer programming is different from building bridges because every time you change code you change everything that interacts with it. Whereas the laws of nature for bridge building don't change, every time you modify code you end up having network effects that effect every instruction afterward. []

    Since most (non multi-core) code happens sequentially. To see this, imagine an extremely simple computer with only a few KB of

  • by crgrace ( 220738 ) on Friday November 21, 2014 @02:07PM (#48435333)

    I'm work for an organization that provides design services (as opposed to building and selling products). If you are ever, ever , realistic about the time it will take to deliver or what features you can include in a design for a given set of resources, you won't get the job. It's as simple as that.

    Why do you think most construction projects go over budget? One big reason is they had to make a crazy bid because if they didn't, someone else would.

    The bottom line is: if you say no, you're out of a job.

  • I've done my time as a technical project manager. I can't say I enjoyed it, but someone had to do it, namely protect the developers from upper management so that they could actually get their work done. One thing it taught me was to plan around 30% of the project time on the requirements. That still seems insane to me, but that's what it takes. That was my time, working with upper management, documenting things, listening to them waffle, and generally refusing to hand anything to the developers until I had

  • The team I work on reports to a senior director who abhors process. His distaste for it comes from his roots as a rockstar developer at a startup. He often says things like "we just need to fix it" or "this should be simple" and gets frustrated in meetings with teams who push back asking for more information. While being very vocal in meetings, he never creates any documentation or requirements to guide teams. Nor does he consider the impact of the changes to, what can only be described as a giant hairball
  • by EmperorOfCanada ( 1332175 ) on Friday November 21, 2014 @06:07PM (#48437263)
    So often I see developers and often their managers being loaded down with things that have exactly zero to do with the project's success. For instance I have seen companies that had an 8am meeting every morning at a company that claimed flexible working hours. These meetings were nothing beyond empty platitudes from a manager.

    Many companies that I have visited had sales dictating what needed to be built in that they would chase every whim of every potential client resulting in 100's of features being built for nobody (didn't get the client) but slowly turning the projects to crap. Then sales would regularly blame the programmers for letting them down by not developing an AI driven natural language database over the long weekend.

    The single worst that I saw was a company where the president's wife suddenly started dictating features. These features were completely unrelated to the core product. It would be like a VW engineer suddenly getting instructions on adding a flower arranging module instead of working on a recall where the cars can catch fire. This had the entire project's staff leave one by one until the project just died.

    But if I had to pin project failures down to a single consistent problem it would be that really terrible programmers who are complete blowhards often get way ahead of their co-workers leaving a trail of fuming resentment in their wake; the primary result is that the most skilled programmers are the first to leave resulting in a rapid plummet of the average level of talent as once the best go often the next best are soon to go, and so on until you are left with only duds who don't dare to find another job.

    As for what system is in place it doesn't really matter much as a talented group will make it work. But if that system is encouraging any of the above disaster scenarios the project will suffer.
  • by wabrandsma ( 2551008 ) on Friday November 21, 2014 @06:38PM (#48437469)

    Corporate Policies requires that developers cannot have so called 'elevated rights' on a server. Any server, including test and development servers.
    Well, that is, the developers have been granted local admin privileges for the development servers, but as a special exception to the corporate policies.

    The daylight savings patch that has to be installed, requires an upgrade of the application on the server, with an uninstall and a fresh install.
    With a full redeploy of the content and reconfiguring connections to ldap, databases, other servers and reconfiguring user autorizations linked to the content.

    The developer documents the deployment procedure in an installation guide.

    Next the the upgrade has to be deployd to the test server, but none of the developers have local admin rights for the test server.
    So, resources from platform operations have to be claimed by the coordinator. For the installation and the finalization of the application upgrade.

    The upgrade takes a little more than the standard 2 hours that have been reserved per week, but finally after a week a slot is available to do the part that has to be done that requires local admin rights for the test server, by someone from platform operations.

    At this point, the system test has slipped by a week, on a monthly release cycle, that is a significant amount of time.

    A couple of day later the upgrade is deployed to the acceptance server for user testing. Except that most of the users refuse to test the changes, because there are no new features. In their eyes it is purely a technical upgrade. Nevertheless a bug has been found, and it is declared blocking. It takes some days to resolved it. By now, due to all the previous delay, the issue has not been resolved in time to get the change in production.

    The monthly release date slips. The next slot available is the next month, and the application gets finally released into production.

    Essentially, it means that if something does not get tested beforehand, like a deployment procedure, it eventually gets tested in production.
    That is the best way to test something, isn't it? A consequence of the Corporate Policies.

    Now I am going to watch some South Park episodes. I like documentaries.

  • I work at a company that tends to be ahead of schedule and so we get time to improve things, and improve things steadily. We're not typically stressed and usually pretty confident about stuff.

    This just reminds me even more how much I love my job.

It's fabulous! We haven't seen anything like it in the last half an hour! -- Macy's