September 20, 2016 at 12:55 pm
roger.plowman (9/20/2016)
I read the article Steve was talking about and it is based on the badly flawed premise "software mistakes have essentially zero cost". That is so breathtaking boneheaded I don't even know where to begin.The assumption seems to be that since you can update quickly any mistake is trivial, and while occasionally true it is by no means a safe generalization. Apple's update that nuked external boot drives a while back comes to mind. Easily and quickly fixed, yes. Zero cost?
Um, no. :hehe:
I disagree with that point. Mistakes have costs. They're lower than the physical world, but still exist.
September 20, 2016 at 12:57 pm
roger.plowman (9/20/2016)
No, no small releases to new systems (other than bug fixes, of course).
The reason I say this is that new systems are not known quantities nor are they stable as a rule. So what looks like a small change might in fact have hidden (and large) repercussions that won't be obvious. Especially if the new system is touching old ones...brrr.
Have several small releases in a row over the span of a week to a new system? Yeah, that's just asking for trouble. You have to give users time to really pound on a system and make sure there are no dragon eggs ready to hatch!
Every time you add a new feature it introduces a huge array of new interactions. Every time. Multiply that by the number of releases and the numbers turn nightmarish pretty darn quick.
[Edit: spelling]
I'll disagree somewhat. The idea of adding new features may or may not introduce interactions. It really depends. However, I do want to limit and control the releases. This usually means we're not releasing anything other than bug fixes daily, but we might add in new features weekly. Or a couple times a week. It really is hard to make a generalization here. It's entirely possible new features can't come for a month.
September 20, 2016 at 1:08 pm
Steve Jones - SSC Editor (9/20/2016)
roger.plowman (9/20/2016)
No, no small releases to new systems (other than bug fixes, of course).
The reason I say this is that new systems are not known quantities nor are they stable as a rule. So what looks like a small change might in fact have hidden (and large) repercussions that won't be obvious. Especially if the new system is touching old ones...brrr.
Have several small releases in a row over the span of a week to a new system? Yeah, that's just asking for trouble. You have to give users time to really pound on a system and make sure there are no dragon eggs ready to hatch!
Every time you add a new feature it introduces a huge array of new interactions. Every time. Multiply that by the number of releases and the numbers turn nightmarish pretty darn quick.
[Edit: spelling]
I'll disagree somewhat. The idea of adding new features may or may not introduce interactions. It really depends. However, I do want to limit and control the releases. This usually means we're not releasing anything other than bug fixes daily, but we might add in new features weekly. Or a couple times a week. It really is hard to make a generalization here. It's entirely possible new features can't come for a month.
Yeah, "how long is a piece of string" stuff. 🙂
Still, any new system (or new version of an existing system) is likely to be non-trivial in size. My point is simply that developers suck at finding bugs, always have and always will. Most SMBs do NOT have QA departments. If you're lucky you have a power user who likes to break things. If you aren't you have a manager breathing down your neck to get the system out the door, testing be damned.
New features almost certainly will add interactions, especially if they change persistent states (i.e. write data). When systems start approaching 100k lines of code releasing a new one even after automated + beta testing does not mean the system is bug free, not even critical bug free, especially in security.
So to then pile new features on top is just wrong. Wrong on so many levels.
Users will find your bugs, guaranteed. And then squeal like a stuck pig. It just takes time. More time than the rapid release folks are willing to believe.
September 21, 2016 at 9:55 am
I think you have to make the determination as to whether your legacy software is stable or whether it is stagnant. The latter is when you are scared to make a change because the impact or determining the impact requires a major investigation which probably won't give you an answer let alone the reassurance you need.
To be able to do frequent small releases you have to architect your system and design to be able to do small releases. If bugs become apparent in live then start with the diagnosis and work back until you have defined a spec for tests that would prevent that happening again.
There cannot be a proclamation that your company will do small releases. A lot of work goes into making small, frequent releases possible and it is a cross functional effort.
My colleagues worked very hard to make it possible to release database code reliably and in small iterations. It was painful getting there but ultimately well worth it. What an IT department cannot do is forever hide behind its legacy software. What you will find is that if the current IT department cannot do something then pretty soon the powers that be will start to recruit a team that can or will drive through the changes necessary to make it possible. Failure to do this will result in the competition drawing ahead.
No company is too big to fail. Great Universal Stores used to be the biggest catalogue retailer in Europe and a blue chip company. They don't exist anymore.
September 21, 2016 at 10:44 am
David.Poole (9/21/2016)
I think you have to make the determination as to whether your legacy software is stable or whether it is stagnant. The latter is when you are scared to make a change because the impact or determining the impact requires a major investigation which probably won't give you an answer let alone the reassurance you need.To be able to do frequent small releases you have to architect your system and design to be able to do small releases. If bugs become apparent in live then start with the diagnosis and work back until you have defined a spec for tests that would prevent that happening again.
There cannot be a proclamation that your company will do small releases. A lot of work goes into making small, frequent releases possible and it is a cross functional effort.
My colleagues worked very hard to make it possible to release database code reliably and in small iterations. It was painful getting there but ultimately well worth it. What an IT department cannot do is forever hide behind its legacy software. What you will find is that if the current IT department cannot do something then pretty soon the powers that be will start to recruit a team that can or will drive through the changes necessary to make it possible. Failure to do this will result in the competition drawing ahead.
No company is too big to fail. Great Universal Stores used to be the biggest catalogue retailer in Europe and a blue chip company. They don't exist anymore.
Absolutely everything you said.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
September 21, 2016 at 10:46 am
Agree, well said, David.
August 27, 2021 at 2:40 am
From the article:
Can a system be secure if you change it multiple times a day?
I cringe every time I see those or similar words. Many will disagree with me but my take on such words is...
If you have to make multiple changes per week on a regular basis, never mind multiple changes per day, there is something seriously wrong with your evaluation, design, coding, testing, and deployment process. You should fix that first because publishing multiple mistakes and the related fixes (some call them "improvements") per day isn't a good idea and that's exactly what you're doing because we all know you're not publishing that many useful new features per day.
Well, unless you're a Borg in battle and you're rotating shield frequencies. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
August 27, 2021 at 8:05 am
If you have to make multiple changes per week on a regular basis, never mind multiple changes per day, there is something seriously wrong with your evaluation, design, coding, testing, and deployment process.
With the obvious caveat of ....it depends. Without design (and I don't mean big design up-front) then a frequent release cycle is not going to give you the benefits you hope for.
Design, careful planning, ground work and adherence to disciplines make frequent releases possible. A lot of the stuff that makes CI/CD look easy is not shiny-shiny. It is the submerged bit of the IT iceberg. Ditto the stuff that makes it easier for frequent releases to add value rather than noise.
An ex-colleague had a genius for explaining concepts in simple and ways that seemed obvious after he had said them. He used group exercises as analogies for software processes. His example for a frequent release was to imaging a cartoon person. You are going to draw that person in an iterative way. Each release must represent the entire person, they cannot be incomplete otherwise you haven't got a person (product).
At each stage the illustration represented a viable person/product with each stage adding detail and features.
Back in the real world people do change their minds, sometimes for good reasons. The trick is to have a design that keeps dependencies to a minimum so that change is possible and practical.
August 27, 2021 at 10:17 am
This was removed by the editor as SPAM
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply