August 21, 2014 at 10:15 am
Perahps most IT development shops in 2014 are in the "Early Industrial Age", where is goal is leveraging tools to crank out a lot of "good enough" code but there is not enough emphasis on process and quality.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 21, 2014 at 11:48 am
Eric M Russell (8/21/2014)
If sufficient functional requirements are not provided upfront, then all these "fixes" in production are really just change requests and phase I, II, ~ deployments. A solution that has been in production for months shouldn't be considered "broken" just because someone wakes up one morning and decides it should be working in a different way.
OMG!!! Allow me to beat the proverbial drum and give this a +1000. I wish people would understand this fundamental concept, but it's a hard sell when they believe that their every whim should already be accounted for by software that they needed finished before they even asked for it.
August 21, 2014 at 11:54 am
Ed Wagner (8/21/2014)
Eric M Russell (8/21/2014)
If sufficient functional requirements are not provided upfront, then all these "fixes" in production are really just change requests and phase I, II, ~ deployments. A solution that has been in production for months shouldn't be considered "broken" just because someone wakes up one morning and decides it should be working in a different way.OMG!!! Allow me to beat the proverbial drum and give this a +1000. I wish people would understand this fundamental concept, but it's a hard sell when they believe that their every whim should already be accounted for by software that they needed finished before they even asked for it.
Second that!
August 21, 2014 at 12:52 pm
In a database world, a long, long time ago, Sybase was king. Then, a version was released that was so bad, it came close to tanking the company. I'm pretty sure in hindsight they wished they did a bit more testing. (and, I sure quite a few of you remember when you needed to buy Sybase books to better understand the early releases of SQL Server).
So, yes, do please test. When I was chief software architect of a start-up years ago, we setup a continuous integration process. code check-ins could invoke a full rebuild, along with a fully automated set of unit tests and end-to-end tests. If you can get a continuous integration process setup, do it. A bit of a hassle at first, but it makes it easier to test.
The more you are prepared, the less you need it.
August 22, 2014 at 1:35 pm
I've been watching a series following the training of the Royal Marines. One of the corporals made the comment that their standards are very high for a reason. They will do everything possible to help the recruits meet those standards but those standards will not be lowered under any circumstances.
They know they are being tough but do be anything else does the recruits no favours. If the bar is lowered then a Royal Marine would be a danger to themselves and, more importantly, a danger to their comrades. Those high standards are why the Royal Marines are an elite group and highly respected.
I've often wished this attitude prevailed in software development. Set high, uncompromising standards to which IT staff have to deliver. Relaxing those standards will have a knock on effect that will be detrimental to the deliverable and return to bite them and their colleagues in the bum.
You may not think this is practical but my personal experience is that the time spent bug-fixing after deployment is far greater than the time spent being a stickler for quality. More and more time is spent coding around buggy and tech debt riddled releases on each subsequent releases.
In my career I can think of only a couple of occasions when the deadline for delivery was truly important enough that it had to be released come what may. The rest have been arbitrary deadlines to allow a manager to claim a bonus. Said managers would accept almost anything in order to get their bonus knowing that the next quarters objectives would have absolutely nothing to do with the software they had just signed off. Someone else would become responsible for the freshly delivered turd and they would get away scot free.
Test your software as if a bug found after deployment would be a proven slur on your bedroom prowess.
Stop complaining and (as the Marines say) "man up princess".
August 22, 2014 at 4:45 pm
Gary Varga (8/21/2014)
Also, I am not seeing companies better able to leverage existing systems or components than occurred 20 years ago.
Gaz, respectfully, your historical perspective might be too short. I do see companies much better able to leverage existing systems and components today compared with 40 years ago. In the longer wave in the cycle, the change is more noticeable.
M.
Not all gray hairs are Dinosaurs!
August 23, 2014 at 7:33 am
Miles Neale (8/22/2014)
Gary Varga (8/21/2014)
Also, I am not seeing companies better able to leverage existing systems or components than occurred 20 years ago.Gaz, respectfully, your historical perspective might be too short. I do see companies much better able to leverage existing systems and components today compared with 40 years ago. In the longer wave in the cycle, the change is more noticeable.
M.
Miles, I totally agree. I do feel that 15 years of stagnation is a long time in this industry.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 25, 2014 at 9:49 am
Gary Varga (8/23/2014)
Miles Neale (8/22/2014)
Gary Varga (8/21/2014)
Also, I am not seeing companies better able to leverage existing systems or components than occurred 20 years ago.Gaz, respectfully, your historical perspective might be too short. I do see companies much better able to leverage existing systems and components today compared with 40 years ago. In the longer wave in the cycle, the change is more noticeable.
M.
Miles, I totally agree. I do feel that 15 years of stagnation is a long time in this industry.
Agreed, 15 years is far too long! Years ago we use to use the slogan "Change or die” We were not allowed because of the creative pushing us to slow. We had to move forward or be crushed by the innovation that was almost daily.
Not all gray hairs are Dinosaurs!
February 2, 2021 at 11:48 am
I would support david.howard suggestion that testing increases over time.
Initially in my career I would size projects at 2:1 ... dev:testing; thus 1/3 of time for testing. Even 1/3 testing was a hard sell to sr. mgmt a couple decades ago.
Of late (the last decade), I've modified that to 1:2 ... dev:testing; thus 2/3 of time for testing (but that includes unit testing).
But from david.howard post, I tend to believe now that starting a large project at 2:1 and over time should observe it begin to approach 1:2. The art of managing dev/testing resources becomes paramount given this reality.
Viewing 9 posts - 31 through 38 (of 38 total)
You must be logged in to reply to this topic. Login to reply