Developer Time is More Valuable Than Ever

  • Kendra Little

    SSC Journeyman

    Points: 80

    Comments posted to this topic are about the item Developer Time is More Valuable Than Ever

  • MVDBA (Mike Vessey)

    SSC-Insane

    Points: 21453

    It’s interesting to think about developer time when it comes to the top two results: the “freeing up developer time” isn’t simply about allowing them time to code more changes which are delivered more quickly. This choice also specifies that it’s important that the time be used for “added value” work: in other words this is related to increasing the business value of the work in some way and not simply related to routine or expected changes to maintain existing functionality.

    I couldn't agree more, I've seen changes pushed so quickly that we get bad code and huge amounts of technical debt.

    BUT unfortunately we do have to maintain existing functionality and reduce that technical debt - which I consider to be "added value",  if we can get rid of that debt then we free up more devs for more new features

    just my own opinion

    MVDBA

  • GeorgeCopeland

    SSCertifiable

    Points: 6913

    Great article Kendra, thanks. Money and budget are the basis of all industry. In my world, the basic unit of money is the developer-hour. Just like other units of money, these are a limited resource.

    Every budget decision I make is about these units. If I mismanage these units my teammates and I will fail.

    The practice of DevOps raises software quality and lowers the amount of developer time that is needed for deployments. Both of these increase the value of developer-hours.

     

  • Rod at work

    SSC-Dedicated

    Points: 33186

    This article, Kendra, comes at a critical time for my work, which in the last 18 months had begun to adopt a more agile approach to software development. We have a Project Management Office (PMO) which had been leading the charge. And it had backing from the deputy CIO. I had thought that all of the Business Analysts were on board with this. Apparently I'm wrong. One of the BA's left to take a new position in another state department. Sprints that were two weeks long suddenly stretched into 6 or more weeks. We've not had a stand-up in two months. I've learned that the BA who left was the driving force behind the adoption of Agile/Scrum. And the deputy CIO who was supporting the adoption of agile, now "has other issues to work on".

    So, it's back to waterfall, where this state agency has been for many decades.

    Now that the whole agile adoption initiative is being abandoned, I suspect that there must have been a lot of people who strongly, but secretly, opposed it. I don't know this for a fact, but I wonder if many of the remaining BA's in the PMO opposed it. They made have perceived the adoption of agile as a threat to their jobs. Now they can spend two or more months coming up with voluminous documentation, charts, graphs, proposed screen designs, etc., before any developer has had a chance to crack open Visual Studio (or whatever IDE they use) and DBAs can open SSMS to design databases, tables, stored procs, etc.

    Very discouraging.

    I'm going to try and use these two reports to show that adoption of agile is beneficial. But it's a higher hill for me to climb than a BA has.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Jeff Moden

    SSC Guru

    Points: 995608

    First, to be sure, I'm not taking a shot at anyone for whatever methodology they use... I'm just talking about what we did in the various places I've worked and most of it revolves around "Developer Time".

    I've found that any shop that adopts a methodology such as Agile, what people think of a DevOps (and I disagree with most people's thoughts on it), waterfall, or what have you in a rigid, inflexible and exclusive manner are ultimately doomed to failure because not all projects will benefit from the use of only 1 development methodology.

    I've also found that Developers are frequently treated and directed as nothing more than oarsmen on a slave galley and must row to the beat of a drum.  That, of course, allows no time for adequate unit testing, partial integration testing, performance testing, innovation, or even time to think things through.

    While I applaud the technology used for Continuous Integration (CI), I've found that CI itself is a part of that beating of a drum and the beating of that drum is responsible for the deployment of insufficient or downright bad code faster than ever before.  That, in turn, causes rework that gums up the whole works and causes management to beat on the drum at both a faster rate and with much more intensity, which causes more of a rush, sanctions improper short cuts to "meet the schedule", and more and more insufficient code is deployed and the technical debt continues to grow like a bad drug habit.

    And then there's the warping of scripture like manifestos and parables by people to meet their own needs.  I think the original Agile Manifesto was well written and spot on but has been warped out to shape to mean that planning (for example) should be relegated to 3x5 cards on a bulletin board.  I think that Knuth's parable about "Pre-optimazation is the root of all evil" is spot on but people have warped that into ignoring the need to document and proper design resulting in thousands of tables in hundreds of databases that contain NVARCHAR(255) for the likes of a column meant to contain ZipCodes and NUMERIC(18,0) for an Age column.

    The world isn't getting any smarter about this either.  Consider what most job descriptions state...

    "Must be able to simultaneously work on multiple time sensitive projects and meet all deadlines."

    That's a bit like telling a janitor that they have to sweep, mop, and wax a floor all at the same time.  What you'll end up with are floors with dirt embedded in wax.  Even well built machines struggle to do the same thing because they can't get into the corners.

    Please don't mistake that for some rigid Design First, finish all the documentation, and then rigidly write code.  If everything that a Developer needs to do had already been done, there would be no need to write code... you'd only need to copy and paste modules (which won't work real well in a database environment even if done "correctly").  I totally agree with a Developer writing some PoP (Proof-of-Principle) code to figure out the best way to accomplish a new requirement.

    That's just not possible in the presence of the proverbial beating drum.

    My bottom line is "Do it right the first time".  If you want it done right in a hurry, then the Developer cannot be made to "simultaneously work on multiple time sensitive projects and meet all deadlines."

    With that, I'll also remind people that "If you want it real bad, that's normally the way you'll get it".  You can't afford such a thing to get to your customers, period... well, unless you have a totally captive audience like Microsoft does and then you can release code that breaks when used, destroys your data when used as designed (anyone remember the problems with Online Rebuilds of Clustered Indexes and code that would wreck you SSIS servers, for example?), create new stuff that only has partially useful features (2008 Extended Events comes to mind), forces unwanted features on people thanks to some ill-begotten "Best Practice" ("Fast Inserts" were killing me... thank goodness that at least had a server-wide override in TF 692. Non-overridable "forced balance file size" {equivalent of TF 1117} on TempDB killed some of my processes because MS also screwed up on SET IDENTITY INSERT ON with a forced sort even when not needed {and is still on the "unplanned" list for a fix}).

    So, what has worked in the shops that I've been in?  Step one is to realize that most people's estimates of how long something will take actually suck for accuracy.  Step two is to realize that no one can actually "simultaneously work on multiple time sensitive projects and meet all deadlines." Step 3 is to finally understand what technical debt and the resulting rework actually does to already-in-place schedules and take the little bit of extra time to avoid it.  In other words, "Do it RIGHT the first time".  Step 4 is to stop making excuses for not doing it right the first time.

    So, I agree... Developers time IS more valuable than ever... but the things we do continue to foster bad and insufficient code and the resulting technical debt, which can only be resolved by the Developers, continues to grow like a bad drug habit.  Unfortunately, we keep beating a drum without checking for pulses on the people at the oars.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply