November 9, 2020 at 12:00 am
Comments posted to this topic are about the item Building Bad Software Faster
November 9, 2020 at 5:23 am
The ability to deploy faster has done nothing for the quality of code, IMHO. I know you didn't say that in your good article but seem to be leaning a bit towards that.
One of the things that I've noticed is that the fundamentals of design haven't changed much because they're good fundamentals. Regardless of how fast we pump out code, there's an "innovation" that everyone should try for a change and that would be to actually plan out the database for performance, scalability, and ease of maintenance for such rules as a "minimum of 3rd normal form" instead of taking Knuth's parable to the extreme of doing no optimization to the point where the design is a conglomeration of worst practices, all to meet some bloody schedule that will ill-conceived and doomed to be late before the project even started.
As a result, we end up letting our customers find issues for us including not meeting requirements, missing or partial functionality (STRING_SPLIT anyone?) that seem silly not have done correctly and, I have to tell you, customers are getting tired of it. I was recently working with one vendor that we let into a copy of our database (thank goodness it was just a copy). One of the vendor developers asked to speak to the DBA (me) to get some help creating a table. No problem... until I found it it was one of the existing tables in the copy of the database and shouldn't have been dropped anyway.
My thought is, slow down, pay attention to detail, and you'll actually end up going faster because you won't have to go back and sweep up the trail of loose nuts & bolts and broken glass nor do any fancy moves to avoid the totally pissed off customer running in your direction with a hammer and fired up chainsaw.
Slow down to go faster. It actually DOES work.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2020 at 2:14 pm
Hey, you guys still out there doing software are in big trouble now. I read that 'Sleepy Joe' has the solution for all the laid-off retail workers in the economy. He says just teach them to code and it will all be solved.
I guess I wasted my forty-two years of learning effort.
The good side is that with where the Dow and Nasdaq futures are this morning, it would appear that by the end of the day I may have fully recovered the 100k+ losses in my retirement funds from last March due to the virus. I'm sure the p. e. will take credit for that.
You may not like our current leader, but you can't knock what he has done for our economy. I'm very near to having MORE in my retirement savings that when I actually stopped working.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
November 9, 2020 at 2:23 pm
In cycling terms there are two terms of disparagement
In DevOps terms you can have the best software, the most advanced infrastructure and it can all be for nothing because it is the human element that is the most important part.
People need to be empowered and encouraged to seek ways of improving what they do. Time and effort needs to be set aside to allow them to do this. This is the "slow down to go fast". If you improve a process then everyone who uses that process benefits. This includes the business features that you were trying to deliver using your existing process.
If you are going to submit a pull request for a piece of database work do you include a profile/extended events trace and execution plan for the queries that are going to happen? Simply making this a mandatory part of the PR process means that devs/data engineers have to at least know how to generate a trace and execution plan. The next step is making sure they understand what it is they are producing and how it can be used to help them do what they do.
I have a test suite of over 100 tests for when I develop new data pipelines. Does it catch every error. NO. But it stops 100 errors I could have made and I am working to find out how to test for the small number that do slip through.
If I have something that can detect 100+ errors then that is 100+ errors I won't get passed back to me to fix because they never got past my workstation in the first place! The time saved means I can spend more time working with business colleagues on innovation.
Of course I don't want to neglect the innovation time when it comes to my own needs. Far better to work out how to improve a process than be crucified on the cross of "This is the way we've always done things"
November 9, 2020 at 2:33 pm
+1 Million, Mr. Poole. Especially on that last thing. It's funny how people will change the tools (sometimes causing huge amounts of lost learning and functionality) in attempt to improve a process but never look at the process itself. It's like putting a Power-Ranger's band-aid on a stab wound.
On the flip side of the coin, sometimes the process and methods don't actually need to be fixed. With the idea of "Slow down to go faster", sometimes all that needs to be done is to actually follow an existing process using some of the well-proven tools that already support the process.
A part of the "Slow down to go faster" notion is that the folks "must look eye" instead creating inadequate replacements with the knee jerk assumption of "if we change it, we'll improve it". In other words, stop being reactive... be proactive and sometimes being proactive means that the changes that folks came up with might just need to be abandoned. That's not a waste of time. In fact, it may save a huge amount of time down the road.
"Change is inevitable... change for the better is not".
--Jeff Moden
Change is inevitable... Change for the better is not.
November 9, 2020 at 4:35 pm
Very interesting article. Fits in with other material I'm reading and listening to. I hadn't thought of the likelihood that developers or DBAs might not want to experiment. After all, I've been hearing the mantra from Mark Zuckerberg, "Move fast and break things", for a while now. But working in government, which is extremely conservative in implementing anything, releasing anything that breaks is normally considered something akin to a crime.
One of my favorite authors is Gene Kim, a recognized expert in the DevOps community and author of the books, The Phoenix Project, The DevOps Handbook and his latest, which I'm going through now, The Unicorn Project. Kim started a new podcast recently called "The Idealcast by Gene Kim". In a recent episode on the book, "Team of Teams", he described the inherit conflict between development and operations. Developers always interested in introducing new features as fast as possible. Operations wanting to never change anything to maintain stability and security. Both have legitimate concerns, especially in the private sector. I'm going to have to listen to that podcast episode again, because I don't think I've yet caught what Kim is saying. I may be getting it wrong, but I'll try to convey what I believe Kim has said. He's saying that the changes DevOps is calling for, are small changes. You introduce small changes, test to see how they work. If they don't, then change them and see again. If they do, then go onto the next small number of changes. Rinse and repeat. That seems reasonable to me and a good compromise between what developers want and what operations want.
Last comment on this. Zuckerberg has changed his mantra to be, "Move fast with stable infrastructure"
Kindest Regards, Rod Connect with me on LinkedIn.
November 9, 2020 at 4:46 pm
I'm reading Team of Teams now. It's fascinating.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply