PreviousNext…

How to work with your developers 06 Sep, 2010

The first part of an occasional, irregular (in every sense of the word) series of posts outlining how to get the best from your developer.

The software developer is a simple soul. Whilst you should keep yours caffeinated and with a steady supply of things to whine about (I think everyone knows those rules), there is a fine line on the “whingeing” part: you can go too far with your developer! Here are some tips to bear in mind when trying to optimise your developer experience. The focus for today’s selection is “Project management” (yes, that mythical concept). Here are some tips:

  • Do not maintain covens of “Business Analysts” whose sole function is to chase developers for the status of any given issue (ignoring the expensive issue tracking system put in place to do just that)
  • Timesheets. Just don’t
  • Do not issue random miscellaneous report requests
  • Do not assign upwards of three issues at once and expect all to be resolved within minutes, whilst running around organising emergency meetings and shouting (this is also known as “flailing”)
  • Multiple issue tracking systems. Pick one, and stick to it.
  • Never send round miscellaneous issues in a random email or spreadsheet (see above)
  • If you assign an issue to a dev, leave it at that. No chopping ’n’ changing!
  • Never invite devs to interminable meetings where issues are debated. Thrash them out first, then communicate the issues quickly. So, you know, the work can get done
  • Developers aren’t so naïve as to expect managers to consult them re deadlines. But can they at least communicate them?
  • Timesheets. Just… don’t
  • Don’t ask developers knee-deep in code to suddenly switch focus and perform deployments. Time-table your releases in all environments, and set expectations accordingly
  • Do not expect your devs to reel off every single change / fix in a given version of the software, past present and future. That’s what you bought that tracking system for (see above)
  • Never say, “Where are we with this?”—that’s what you bought that tracking system for (see above)
  • Estimates (AKA “guesses”) should not become absolutes
  • Fucking timesheets. No no no!
  • Do not combine two disparate issues into one. Once the developer has worked on part 1 for day or so, proceeding to tell him or her that part 2 is the vital bit, (“in fact we need it in UAT, like ten minutes ago!”) is likely to cause mayhem

I hope this has been educational and insightful; please feel free to add to the list in the comments…

Filed under, ,

Comments

  1. How about:

    Dont assign more testers than developers

    When a tester opens a defect, dont re-open it for a spuriously connected issue

    Defect status should be honest. A UI issue is not a showstopper

    When your devs tell you more than a year ago that the app will only work with IE6, and will fail with IE7, and that desktop support has started rolling it out - dont be surprised when your decision to NOT support IE7 (or IE8 or Mozilla) comes around and bites you in the arse.

    Mindalign is NOT IM.

    ---* BillBill Buchan#
  2. Testers? Oh the luxury!

    We often see a 1:1 developer:tester ratio—each developer is also the tester.

    That works, right? ;-) Ben Poole#
  3. I would add:

    > Telling the development team of your key requirements one at a time as the project progresses does NOT make things easier/faster

    > Just because you can record a macro in Excel does not mean that you can tell a developer the best way to design/ modify an enterprise application

    > If your developer shows you 1000 lines of code that they have just written then tell them that it is fantastic and that they are really really clever, even if you have a better chance of reading and understanding Homer's the Illiad in the original Greek.

    Try this to see how NOT to interact with your developer (warning: contains strong language):

    http://www.youtube.com/watch?v=VfprIxNfCjk

    (BTW the web site that was used to create that video is really clever and well worth a visit!)

    Melissa Snell#
  4. And:

    Know the difference between a defect and a new requirement and flag accordingly in whatever system you are using. If you dont know ask the developer(s) it may be a show stopper.

    Dont expect developers to work on more than x+1 projects at once. X being the figure the individual developer is comfortable with. Feel free to +1 if we dont have to do frickin timesheets for each project/requirements/issue.

    For Developers:

    Get every requirement documented and ideally signed off by all interested parties. You will get shafted still but at least you can bite back a bit.

    -- ZJohn Z Marshall#
  5. I think you should also mention timesheets!
    Pedro Quaresma#
  6. Always have a time reserve !
    If you assign a task to a developer and give him whatever time for it, then he will always use it up completly. (Well any code can be tweaked and improved) So expect already upfront that to be the minimum time for the task and save some additional time reserve for unexpected problems.
    Hynek Kobelka#
  7. And remember, your Contractors are people too, and also need hugs. Don't copy them in on an email to employees outling bonuses of between 15% and 40%, after cutting Contractor rates by 10%. Its just not clever. Really.HughsterRooster#
  8. "interminable meetings where issues are debated"
    I 've learnt to love those. Its kind of absurd theatre!

    New, unfortuatedly a wee bit complex one could be:
    You are answering the objections of a developer with words like: "Well our profesional tools from vendor x will take care of that". Suddenly that developer starts behaving like in an epilectic seizure.
    Talk with the developer later. He might have something important to tell.

    A fresh, very specific one (not yet 100%, but sadly 99,9% sure):
    Don't ever use Rational Synergy for a 6 persons team in the same building. Use svn or git.

    axel#
  9. Mr poole

    I feel I have to take issue with your otherwise excellent treatise.. you did notwntiom beer not once … adequate beer us a set requirement for ssadm prince and agile projects!steve mcdonagh#
  10. @Steve. Beer (and other relevant beverages) is too important to be left in the hands of project managers et al. It is incumbent upon every right-thinking developer to make his or her own arrangements in that regard.Ben Poole#
  11. xx. Don't ask me to QA my own work. I love it and it will come to no harm in my hands and besides I know how to make it work why would would I wan't to use it any other way?Jason#
  12. 1)Let them dress casual and work flexible (Career in Development is not a 9-5 job)
    2) More than deadlines, have absolute and solid targets.
    3) Know their work…
    4) Still don't use timesheets :)
    Serdar Basegmez#
  13. ok I know this is as much a joke as not, but let me ask a serious question. how would you measure one without timesheets if that person is a consultant? I get that if you hire a developer in house, you should ignore their day to day time and just measure them on milestones and task delivery (and that should be kept, measured, and reviewed) - but without a timesheet, how does one know what to pay and what was done? John Head#
  14. Hi John. Well yeah, that was partly in jest. To date, every timesheet system I have ever been acquainted with has been all about fibs: politics over whose time code gets used / doesn’t get used, teeming and lading time spent, all that nonsense.

    The actual notion of logging time expended on a project is, of course, not a bad one. Implementation, however, is extremely poor in many organisations.Ben Poole#
  15. Timesheets that say I worked x hours on this day are OK, except when you have to do it 3 times. Like a contract I did in Perth WA where I had to do one for the company I worked at, on their form, another for company that put me in the job, on their form, and another for the company that hired the company that put me in the job, on their form. And each one had to be signed by the boss of the guy who supervised me. That was fun every week. But logging time against codes is a nonce. As already indicated above it ends up purely political and most supervisors hate you putting time against their codes, even when you are allowed to. Banks are bad for this and mostly it comes down to the user pays system. Division A must foot the bill when they ask Division B to do some work, and Division B will screw Division A for every cent they can get, and Division A? Will. Get. Screwed. Team work and productivity at it's best ;)Bruce Langner#
  16. "covens of Business Analysts" - hilarious.

    I was part of a coven of Business Analysts right out of college. I still don't get how it takes longer to get from 99% complete to 100% complete than it took to get from 0% to 99% complete….

    I realized the "reward" for being a good Business Analyst was becoming a Project Manager, which is basically the same job except everything is your fault. Makes sales look appealing.
    Lisa Duke#
  17. You forgot to mention my pet peeve… NO TimesheetsPeter Presnell#
  18. Listen to the objections of your developers carefully.

    I have had managers or clients force a functionality or a requirement against my express recommendation (e.g. Maintainability problems in the future, scalability, security issues), and then get annoyed when 6 months later a system grinds to a halt. As a developer I always had written proof of my objections.

    Sometimes, as a manager, it is better to scrap a requirement, or a functionality, if the cost is too high.

    Andrew Magerman#

Comments on this post are now closed.

About

I’m a developer / general IT wrangler, specialising in web apps, the mobile web, enterprise Java and the odd Domino system.

Best described as a simpleton, but kindly. Read more…