January 8, 2020 at 12:00 am
Comments posted to this topic are about the item A Problem with Cowboy Coding
January 8, 2020 at 11:56 am
Funny - sort of - as I get the feeling the more (better) Code or Consulting I provide to my customers, they likely want to keep me around longer than we've first agreed on. In my current project I was tasked to make the old environment fly again ( down from 9 to 5 hours, 6 months of time and budget was planned for that ) - after rebalancing data to multiple Files & Filegroups which took me about 3 weeks (yes, it was monkey work mostly c&p, replace FileGroup with new one etc.) there was some "unexpected free resources" for my customer so we did something else for 4 months and spent another month figuring out that the customers Cloud Provider (private Cloud, no big name like AWS or Azure) is screwing our nightly loads with their VM Backups.
Anways fast forward to GetDate() I've already spent another 12 months with the same customer and at very least another 3 months it's going to be, not sure how valid the statement is across the whole company but at least for the IT-Department I seem to be both the most expensive and "longest around" external Consultant, tho about the first part the customer doesn't care because at least it seems my work is worth it. They even attempted to hire me as an internal employee but we have a rather large income gap between company policy and what my current employee is paying me, tho I've heard rumors that policy is up for discussion - Evil me! 😉
January 8, 2020 at 1:29 pm
Automating processes is a double-edged sword. As one wit put it "It makes mistakes faster than ever!". 🙂
And yes, managers ALWAYS view automation as a way to cut payroll. Full stop. No exceptions. Mostly because it's true. As a result the margins get thinner, safety nets are eroded, and QA becomes a fond memory. And "productivity" (lines of code) goes up. The board is ecstatic, and all those troublesome bugs are just a cost of doing business.
After all, you can always improve the code later. Except, wait, there's a brand new function that needs adding, forget dusting for cobwebs (i.e. fixing major flaws) in the old code!
Cynical? Of course. True? Usually. 🙂
DevOps is a good idea, but not for all the usual suspect reasons. Certainly it allows creation of a process that is repeatable. Certainly allowing the computer to perform the steps insures consistency, and can even prevent errors.
What it should not be used for is increasing development speed. Or replacing dedicated QA human resources. Automated tests are a good thing, I love them--but they come at a cost. They catch the easy stuff, true. But in today's complex world the easy stuff isn't the problem. The problems come when you hop up and down on alternate Thursdays and type slowly (but only at 3:15 PM) instead of quickly while not reciting Murphy's Prayer in the key of C.
In other words, nearly unreproducible errors that can only be caught by people who know how to reproduce the irreproducible so developers can actually fix it.
Oh, and this can take days for even one bug (as management has a collective coronary).
DevOps? Yes, please. But give me a heaping helping of QA resources to go with it!
January 8, 2020 at 3:46 pm
DevOps doesn't remove the need for QA functions. It might say that we blend that into the development team, but there is still the need for testing. Most DevOps shops (even the popular ones in the press) also still have manual testing. Maybe not for every change, but they do go through the app, looking for things not caught by automated testing.
DevOps does appear to go faster, and it feels faster, mostly because you release small changes more often. However, the aggregate of changes across a quarter isn't likely to be more than in the past. The "faster" is a rate of changes being made, not a volume of total changes.
What this does do, however, is focus changes in areas where your org finds them valuable. You don't go for months on a feature that won't get used.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply