February 14, 2020 at 12:00 am
Comments posted to this topic are about the item Developer Time is More Valuable Than Ever
February 14, 2020 at 9:36 am
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
February 14, 2020 at 2:08 pm
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.
February 16, 2020 at 3:09 pm
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.
February 16, 2020 at 4:54 pm
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
Change is inevitable... Change for the better is not.
February 17, 2020 at 9:32 am
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.
Sadly your BA was acting as a scrum master.. if you want to go back to Agile/Scrum then that's who to hire
MVDBA
February 17, 2020 at 9:39 am
NUMERIC(18,0) for an Age column.
Jeff???? really - you have an age column? whoever did that needs a beating - even as a 16 year old (a long time ago) we were taught to use Date of birth (people do get older you know) then you have the lovely "date" type of field with lots of nice tricks like "datefiff" etc etc...
MVDBA
February 17, 2020 at 2:32 pm
Jeff Moden wrote:NUMERIC(18,0) for an Age column.
Jeff???? really - you have an age column? whoever did that needs a beating - even as a 16 year old (a long time ago) we were taught to use Date of birth (people do get older you know) then you have the lovely "date" type of field with lots of nice tricks like "datefiff" etc etc...
Heh... oh hell no. I don't have an age column... THEY do and, at the time, I had no say so.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 17, 2020 at 3:00 pm
MVDBA (Mike Vessey) wrote:Jeff Moden wrote:NUMERIC(18,0) for an Age column.
Jeff???? really - you have an age column? whoever did that needs a beating - even as a 16 year old (a long time ago) we were taught to use Date of birth (people do get older you know) then you have the lovely "date" type of field with lots of nice tricks like "datefiff" etc etc...
Heh... oh hell no. I don't have an age column... THEY do and, at the time, I had no say so.
lol "THEY"
It does feel sometimes that a DBA's life is Us vs THEM just because THEM are stupid 🙂 - but I've grown nice as I get older and I've stopped hitting them when I shout (HR Rules) - just out of interest did you educate them "Correctly" in the use of DOB fields???
MVDBA
February 17, 2020 at 3:56 pm
Jeff Moden wrote:MVDBA (Mike Vessey) wrote:Jeff Moden wrote:NUMERIC(18,0) for an Age column.
Jeff???? really - you have an age column? whoever did that needs a beating - even as a 16 year old (a long time ago) we were taught to use Date of birth (people do get older you know) then you have the lovely "date" type of field with lots of nice tricks like "datefiff" etc etc...
Heh... oh hell no. I don't have an age column... THEY do and, at the time, I had no say so.
lol "THEY"
It does feel sometimes that a DBA's life is Us vs THEM just because THEM are stupid 🙂 - but I've grown nice as I get older and I've stopped hitting them when I shout (HR Rules) - just out of interest did you educate them "Correctly" in the use of DOB fields???
I told them when they hired me that I can be a walking HR violation and that they should seat me near people that are not easily offended when I start talking in "DBA Tongues" while reviewing code. My general rule of thumb is that if I get up to 3 WTFs during the review, I summarily reject the code and call the Developer over to my desk for some friendly, helpful, kind, courteous (and a few other Boy Scout attributes) mentoring. It normally works out pretty well, especially with the good folks that I work with now.
As to the question about did I educate them about DOB columns, my answer would be "Is a frogs butt watertight"? 😀
I was amazed at one shop I worked at. I asked the "developer" (quoted lower case insult intended here) about the NVARCHAR(255) and NUMERIC(18) junk he wanted me to deploy to production. I wanted to strangle him to end his gene pool when he looked at me, rolled his eyes, sighed, and stated "Premature optimization is the root of all evil". What was really bad was he was the Lead Developer and he was teaching his garbage to the other "developers" that should never have been hired even as Junior Developers in Training.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 17, 2020 at 4:21 pm
Just set 'em all to sql_variant then, great idea.
February 17, 2020 at 4:43 pm
I think you are right, Mike. I'm certain that in my position I don't have the clout to effect change. Developers and DBAs are viewed as people who keep their heads down and bang code (C#/SQL/what-have-you). Only someone at the BA's level can effect that right change as they're perceived to be the only ones at the interface between customer and technical.
Kindest Regards, Rod Connect with me on LinkedIn.
February 17, 2020 at 4:49 pm
I told them when they hired me that I can be a walking HR violation and that they should seat me near people that are not easily offended when I start talking in "DBA Tongues" while reviewing code. My general rule of thumb is that if I get up to 3 WTFs during the review, I summarily reject the code and call the Developer over to my desk for some friendly, helpful, kind, courteous (and a few other Boy Scout attributes) mentoring. It normally works out pretty well, especially with the good folks that I work with now.
As to the question about did I educate them about DOB columns, my answer would be "Is a frogs butt watertight"? 😀
I nearly fell off my chair laughing at that... the number of times I've sighed and then shouted "which F**K*NG idiot wrote this morinic code... then turned around and they were standing behind me. - there is a certain amount of "backpedalling" when you curse in the office, especially when you have your headphones on and you don't realise the chief exec is giving someone like the CTO of wallmart (i made that up) a tour of the building
MVDBA
February 18, 2020 at 8:46 am
I think you are right, Mike. I'm certain that in my position I don't have the clout to effect change. Developers and DBAs are viewed as people who keep their heads down and bang code (C#/SQL/what-have-you). Only someone at the BA's level can effect that right change as they're perceived to be the only ones at the interface between customer and technical.
That is very frustrating. a BA can often tell us that "we don't understand the business requirements" and we counter argue "you don't understand the technical requirements/restrictions"
I'm not a fan of the BA role, but I know they can be an Ally at the same time as an enemy (depends on which sales guy is shouting at the BA and if the BA has had coffee and chocolate)
MVDBA
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply