Software development slow because 'Most of our ideas suck' If you want a vision of the future of software creation, imagine a boot process spinning up a server, forever. Speaking at Continuous Lifecycle London* on Wednesday, Mike Roberts, co-founder of consultancy Symphonia Cloud, employed less Orwellian terminology for tomorrow: continuous experimentation. Perhaps you've heard of …
I prefer the one in the title: 'Most of our ideas suck'
Systemd is ONE of those that suck. So's the 2D FLATSO crap (including Australis). And yet, these ideas that SUCK have been foisted upon us, the customers, by aggressive "developers" who fail to realize that THEIR IDEAS SUCK.
Perhaps they need to stop trying to solve problems that do NOT exist? Oh but THEN their very existence wouldn't be JUSTIFIED and SMUG MILLENIALS wouldn't be able to CRAM THEIR CRAPWARE into our collective orifices, because they *FEEL* it's better, and it makes THEM FEEL GOOD to do it!
Yeah, it's all about "the feel" with those idiots. I'm glad someone's being HONEST about "most of our ideas suck" for once.
Old school inventors already knew this - I have to wonder how many times Edison tried to make a light bulb work by trying hundreds of configurations before he found one (carbon), which wasn't even the BEST material [but was the first one that worked well enough].
"I prefer the one in the title: 'Most of our ideas suck'"
I think that most would agree (that most ideas suck), the very big problem is:
Who determines that the idea sucked and should die a violent death? Because it's certainly not the customers, at least in the SystemD case (or Gnome3, Unity, TIFKAM...the list goes on). As far as I can determine, it's usually someone that has a vested (i.e. financial) interest that determines whether an idea remains or not.
I'm very glad that we (as a consumer and computer professionals) still have at least some level of choice, but that is rapidly disappearing - sadly, that choice may be completely gone within a couple of years.
"Science labs do that all the time."
Science labs spend lots of time and money to write lab policies, build safety systems, plan for contingencies and the like, which appears to be at cross-purposes of this "continual" experimentation -- taking the cautious reaction out of a caution warning (see icon).
Interesting. I didn't get that idea, where it sounds like they want to just test in production. All I read from this article was "think of new ideas. Test them. If they work, keep doing them". One possibility is bad, because it leads to code being almost certainly broken and nobody caring about it. The other one is also bad, because it sounds like they think we've never thought of the concept of brainstorming and testing ideas. Which is worse?
What's missing in this commentary is how you determine which ideas such and which are great. That's a key area where I think the industry is losing its way. The difference between good and bad ideas is whether or not they bring benefit to the customer.
The trend has been to shift to telemetry to try to divine what's good for the customer and what's not, but that's really just made the problem worse in many ways. Given metrics, software houses have begin to think that the metrics reveal everything you need to know in order to improve software. While metrics are certainly very valuable, they also leave out a ton of equally valuable human information.
I remember when the release of software updates was something that people anticipated with excitement. Increasingly, software updates are being view with dread now, and this loss of real customer focus is, I think, the primary reason why.
These days any intersection between usable features and what is actually delivered is pure luck. Vendors have a clear roadmap and agenda that maximizes profits, lock-in, etc., and are delivering what works best for THEM. All you have to do is look at Windows 8-10 to see the sad reality.
The difference between good and bad ideas is whether or not they bring benefit to the customer
Be careful what you wish for:
Marketing Droid 1: "Hey, let's scrap passwords - The benefit to the customer would be less hassle when they want to use their account."
Marketing Droid 2: "And bug fixes! They delay the releases of the new shiny!"
Oh, I see Cisco and Microsoft are on that already
The difference between good and bad ideas is whether or not they bring benefit to the customer.
That should always be the primary focus. If you aren't focussed first and foremost on your customers, one of your competitors will be.
However, you can bring benefit to your business without it specifically adding advantage for the customer, such as by reducing your run cost you can increase your profitablility (if you don't want to pass the entire cost cut on to your customer). Depending on where you sit in the debate, that might be migrating to the cloud, or bringing cloud back on prem, for example.
So just try anything at random. Is that the message?
It works for evolution. And evolution doesn't even have a goal. Yet lots of things tried at random ended up with the likes of you and me. You can't deny that it works.
Yes some might stick, but you'll have no real idea why.
Neither does evolution. It still gets results.
Of course, there's a hell of a lot of wastage with evolution. And you end up with a lot of strange quirks, like the Koala's pouch opening downwards, and flatfish such as plaice and halibut looking like Picasso designed them, and the recurrent laryngeal nerve, but it works.
OK, designing software this way will, like evolution, mean that 99% of changes are for the worse. So as far as the end-user is concerned, no real difference to what we have now.
Quote: "Over the past 20 years,...the lead time for delivering software has come down significantly. It used to take years. Now it's more like weeks."
Do you know why?
Because many more people are developing software!!
Also, I get the feeling that twenty years ago people put a lot more effort into developing bullet-proof software. These days they seem to be aiming for software that'll hold together just long enough to make it to the next patch release.
We have this concept called "Minimal Viable Feature", it means our codebase starts off fresh, and gradually gets filled with utter shite - "it passes the product owners acceptance test, it passes the unit and functional tests, who gives a fuck how it is written".
When we do TDD, its "red-green", we skip "-refactor".
Because scrum teams are flat, its not acceptable to critique peoples code in review, we can only point out things that are actually incorrect, and not stylistic or complexity related.
Still, we can release code 5 times a day, so it must be good, right?
Because scrum teams are flat, its not acceptable to critique peoples code in review, we can only point out things that are actually incorrect, and not stylistic or complexity related.
Why not? It is in my team. Moreover, it is expected.
If you can make my code better, do it - just explain why it is better. If I can do the same for yours, then it may be done (depending on priority etc). Ego has no place in software development - its what leads people to behave like assholes and expect to get away with it, while producing software that may not be all it can be.
Its great in principle, but sadly we do not get to pick our co-workers (well, I suppose that there is the nuclear approach). In my team, certain members will complain that they are being picked on if you critique their code. Typical confrontational people who feel that every discussions is a fight and they want to win. If they wrote it, they'll defend it to the death - "that's, like, just your opinion" etc.
No fun.
Spot on.
Now it is all about getting to the end of the 'scrum' and putting what didn't get done into the next one or on the ever increasing list of Technical Debt (that never gets addressed naturally)[1]
It is all about never admitting that the design that was proposed and had accepted was shite, an evolutionary dead end, ran like a one legged dog, would not scale etc etc etc.
There is never time to go back to square one and take the learnings from what sucked and do it right.
Over the past 20 years, he explained, "the lead time for delivering software has come down significantly. It used to take years. Now it's more like weeks. We have the opportunity to bring this lead time down further to days or hours."
Thanks to the Internet. It's a case of "release now and download updates/fixes later" instead of "adding all features/fixing the problems" before release.
Over the past 20 years, he explained, "the lead time for delivering software has come down significantly. It used to take years. Now it's more like weeks. We have the opportunity to bring this lead time down further to days or hours."
My emphasis. So there you are: all waterfall developers from 20 years ago were incompetent; and all current Agile developers are lazy bastards because you're taking weeks when days are all that is required.
It must be true - Mike Roberts said so.
"Thanks to the Internet. It's a case of "release now and download updates/fixes later""
There's truth to this. Before the web it really was quite difficult to deliver patches. It required physical media and an instruction booklet. And that shrink-wrapped packaged had to be got to the user. That cost money.
These days there's no need for physical media or instructions, because it's automated. The cost is just the bandwidth (or not, if it's peer-to-peer).
"Most of our ideas suck," he said, attributing the quote to software consultant Jeff Patton (though any cynic, unbidden, will say as much).
"But some of them are amazing," he added. "If we can try enough of these ideas out, we can play a numbers game. We can find that ideas that will really help our customers."
Isn't this essentially the same idea that if you put enough monkeys in a room with typewriters that eventually one will create a master piece?
https://en.wikipedia.org/wiki/Infinite_monkey_theorem
So what does that say about developers that are proponents of this idea?
Isn't this essentially the same idea that if you put enough monkeys in a room with typewriters that eventually one will create a master piece?
https://en.wikipedia.org/wiki/Infinite_monkey_theorem
So what does that say about developers that are proponents of this idea?
I think, emphasis on think, because trying to obtain a fact from the guys river of verbal bs isn't easy, this idea is that your customers might not know or be able to express what they want, and iterating over new features quickly and gather their feedback should allow positive change to occur incrementally and rapidly.
However, it seems to me there might be a few flaws in that plan. Lots of customers don't enjoy chnage - they know how to work the existing interface and if you force them to learn a new one, they could just as easily learn a competitors.
I'm generalising here, but: The young want change, the old want stability. Its a progressive scale.
So, where are your users on the scale? If you have a monopoly you might be in a position to force upgrades, but if you're a commodity, then you can't. If your 'upgraded' users aren't self selecting then you're really just pissing on their chips over and over and...
"Lots of customers don't enjoy chnage - they know how to work the existing interface and if you force them to learn a new one, they could just as easily learn a competitors."
Judging from the continued desktop domination of Windows and Ubuntu Linux, users are much more likely to stay with the brand they have been with for a while, than to move to anything with a different brand name.
actually, for most things, 'structure diagrams' replaced flowcharts a long time ago. It's part of the whole "top down programming" thing, which [of course] is *SUPERIOR* to whatever horrible "most of our ideas suck" process that generates things like Win-10-nic, FF Australis, gnome 3, systemd, ...
(that is because top down methodology defines the actual functionality FIRST, instead of moving the target continuously until you feel like you're "done")
Good luck trying 'continuous experimentation' in software that actually *matters* like healthcare.
"That update you put out last week has directly contributed to three patients being mis-diagnosed, and one of them has died as a result!"
"Ah well, chill, man, we were just experimenting, I'll bang out another release with a fix in it later today."
Can I be a speaker at next year's event? I've got a scheme to remove the G from gullible and I need £200 mill in venture capital to get started; I should raise that from that shower in about 10 minutes, and sell them three London Bridges while I'm at it ...
"Good luck trying 'continuous experimentation' in software that actually *matters* like healthcare."
Or pharmaceutical manufacturing. Or chemical manufacturing. Or power generation. Or a dozen other industries I've written software for in the past forty years.
Many great comments already!
"something many startups have done"
I get a tad worried not only when the supporting argument for an idea just so happens to have a ridiculously high failure rate, but that further the evangelist does not even see it!
"When we treat engineers as just code robots, we're not really releasing their full potential"
As opposed to what? Code monkeys or script kiddies? May be a good idea for your UX department, but your platform logic coding should probably be done with the methodical reliable accuracy of a robot.
There's nothing new there -- that's just Sturgeon's Law.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
