September 13, 2017 at 8:21 pm
Comments posted to this topic are about the item I Will Write Bad Code
September 14, 2017 at 6:05 am
Me too! Nothing to be ashamed of except for a lack of effort in trying to reduce mistakes and keep improving.
September 14, 2017 at 6:36 am
The biggest problem with DevOps philosophy is human, not technical.
Management sees DevOps as a way to deliver software faster. Full Stop.
Yes, you can delivery patches faster but unless there's a huge problem (read PR disaster) management won't authorize it. Technical debt will just pile up faster and quality will slide before the holy mantra of SHIP IT. C-level suits just sanction and institutionalize that attitude.
Why yes, I am a cynical old man. Why do you ask? :laugh:
September 14, 2017 at 6:37 am
Process will help as long as you have good, skilled people and good management involved in the process. But if your top executive in change of security has music degrees instead of STEM degrees and experience, or if you have a lousy networking specification like Bluetooth, you can make a difference in millions or billions of peoples lives! (Not in a positive way...) :angry:
September 14, 2017 at 8:21 am
I think I write my worse code when I have to bug fix a previous employee's code. This is particularly the case where there is bad design and there is not the time to rewrite it - I once estimated four hours to patch, four weeks to rewrite. You can guess what happened! 🙁
Like all people I write bad code at times particularly when under time constraints!
September 14, 2017 at 9:07 am
I'll add another way that leads to writing bad code. When you've been told the wrong thing about some feature or dependent system to the solution you're working on. That happened to me just last week. I was completely oblivious to the fact that what I was told 2 years ago was in fact wrong. Oh well, the whole thing has been put on hold now anyway.
Kindest Regards, Rod Connect with me on LinkedIn.
September 14, 2017 at 11:10 am
Or the "analyst" gives you 20 pgs of "assumptions" without real use cases or samples. When things go south, she waves assumption #17 part a division 1 on the bottom of page 4 at you.
If you try to write your own use cases, she yells that you didnt properly read her document.
So glad i left that gig!
September 17, 2017 at 4:18 pm
roger.plowman - Thursday, September 14, 2017 6:36 AMThe biggest problem with DevOps philosophy is human, not technical.Management sees DevOps as a way to deliver software faster. Full Stop.
Yes, you can delivery patches faster but unless there's a huge problem (read PR disaster) management won't authorize it. Technical debt will just pile up faster and quality will slide before the holy mantra of SHIP IT. C-level suits just sanction and institutionalize that attitude.
Why yes, I am a cynical old man. Why do you ask? :laugh:
Well, I do tend to laugh. I've had experience of C-level suits firing senior management people (a few levels above my grade) for trying to over-rule my (as a mere technical expert) determinations of whether we should or shouldn't do something, or arguing about the timescle I was prepared to offer it in. When that happens, it's a nice experience to be working with the C-level suits. I tend to trust the C-level suits far better than I trust middle or senior management below that level. C-level people can often understand what's happening when some middle manager in development decides to hit the release date regardless of how thoroughly that requires violating customer contracts.
Getting back to the real topic, yes the biggest problem with devops is people, not techical. Strangely enough, the biggest problem with the waterfall approach to development and release is people, not technical. The problem in both cases is with four particular classes of people:
(i) consultants who want to be paid as soon as possible so will tell you anything that sounds like they've finished their work even when they have left you deeper in the shit that before they got involved;
(ii) consultants who explain to your superiors how you and your people have ignored their advice when it's absolutely clear that the problem is that you and your people have followed it;
(iii) middle or senior (but not top level) managers who think they can have what they want even when the technical experts point out it's impossible and then succede blocking communications between the technical people and the top level management so that they don't get told it's impossible (and I suppose top level management are partly to blame for letting that last one happen)
(iv) quality consultants who tell that such-and-such an approach to development procedures will eliminate all need for testing before release.
Incidentally, my references to consultants are equally to "technical"consultants and to "management" consultants (and to the worst bunch I ever came across, "quality" consultants).
Tom
September 17, 2017 at 4:46 pm
I failed to say in my previous message that I mostly agree with Steve's editorial (actually, I think it's a great editorial). Like him, I know that I write code that doesn't work - often it's because the world isn't what the specification says it i,s for example the world never contained any company X code for product Y that did what comany X said it did - I won't name any culprits because I don't want any of the companies that sold appalling crap to sue me) and at other times it's because the requirement was wrongy stated and yet other times it's just my own fault I don't always get things right.
I don't think devops makes any difference to how much people doing development get wrong. What it does is enable them to fix things sooner when they do get them wrong. If devops is done properly - test-oriented development, serious integration tests and system tests, errors detected fixed as soon as possible, systems released (to production or to customers) as soon as possible after system tests and/or acceptance tests - then devops will leave the customer with a much happier experience than "the waterfall approach" or any similar nonsense. But one has to remember that acceptance tests may have to be less frequent than releases, unless they can be done on the live system so that they don't count as down time, which may not be an acceptable approach for some applications for some customers.
Tom
September 17, 2017 at 4:56 pm
It also depends on the culture you work in - your environment. In a mature environment, people want to get the job done and they want things to work well. In an immature or overly-politicized environment, it isn't about the product. It's more about not being the one to blame when something goes wrong. The phrases "wait...I sent an email" or "I got my part done on time" come up. So does denial of ever doing something and CYA-style emails that do nothing except contribute confusion on all fronts. We see people unwilling to change no matter how bad things get because "that's the way we've always done it" and similar statements.
When the people, or the culture, are immature, political or paranoid, everything becomes much more difficult.
September 17, 2017 at 8:51 pm
Ed Wagner - Sunday, September 17, 2017 4:56 PMIt also depends on the culture you work in - your environment. In a mature environment, people want to get the job done and they want things to work well. In an immature or overly-politicized environment, it isn't about the product. It's more about not being the one to blame when something goes wrong. The phrases "wait...I sent an email" or "I got my part done on time" come up. So does denial of ever doing something and CYA-style emails that do nothing except contribute confusion on all fronts. We see people unwilling to change no matter how bad things get because "that's the way we've always done it" and similar statements.When the people, or the culture, are immature, political or paranoid, everything becomes much more difficult.
Then there's the culture where a lot of people aren't interested in working together with others to arrive at the best way forwards, they are only interested in getting their own way. And people who find they can't do something that they've proposed to do, but don't admit it and pretend that it's just around the corner for long enough for a lot of resource to be wasted by other people who do work based on the availability of the thing that's not being done.
Mix a collection of those with some of the blame-dodging and blame-attributing CYA gang and some "we've always done it wrong that way so why change now" types and put some marketeers and accountants in positions where they make technical decisions and there's little or no chance of the enterprise surviving for very long.
During the brief time I was in such an environment I didn't write any bad code - I was kept too busy with stupid bloody politics to write any code at all.
Tom
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply