July 1, 2024 at 12:00 am
Comments posted to this topic are about the item The Cost of Rework
July 1, 2024 at 11:02 am
I totally concur. Back in the late 90's and early 2000s Hoshin Principles; Greenbelt and Blackbelt training; Design-for-Six-Sigma, all stressed the importance of the "voice of the customer" and "no-value in rework". Hoshin stressed the importance of doing the job right the first time. Like you, I am amazed at the poor level of management that is more focused on meeting timelines and deadlines instead of focusing on the quality of the work. Too many coders today are more concerned with producing a quick fix. They are failing to take the necessary time to do proper research and questioning to avoid issues that result from poorly thought-out code. And as long as corporations/companies scale back on the wages, they will simply reap what they sow: buy cheap labor - get shoddy results.
July 1, 2024 at 11:10 am
I work with someone I regard as the best architect/developer/data engineer I have ever met. I he wasn't also a gifted teacher/mentor then the combination of skills and seemingly inexhaustible memory would make him intimidating.
Even he looks at his old code and blushes. What tends to get lost to history are the constraints under which the original code was written. No matter how good someone is they are still constrained.
When I had to migrate to databases other than SQL Server the absence of the RedGate toolbelt was painful. Tasks that the various Red-Gate tools made almost muted background noise became strident, requiring conscious effort. If I was asked to estimate a task, post SQL Server, I would almost certainly estimate too low.
Today, when I am developing data pipelines I have VS Code and PyCharm, both with a number of useful extensions that weren't available to us when some of our older code was written.
We use Terraform for IAC (Infrastructure As Code). Early versions did not have the concept of loops leading to a lot of CTRL C+V code. Syntax and data types could be bizarre. This resulted in unavoidable complexity. If we wrote Terraform code today the existence of loops, syntax improvements and tooling would both simplify and shrink the code base dramatically. Unfortunately what we do is akin to maintaining a ship while it is at sea so improvements are constrained.
It's hard to sell a rewrite. It's time and money to improve things the customer never sees.
It is difficult to get a man to understand something when his salary depends on his not understanding it.
If you try and sell a rewrite on the basis of a customer getting something additional as well as the rewrite then my experience is that this results in a death march project.
July 1, 2024 at 11:41 am
I totally concur. Back in the late 90's and early 2000s Hoshin Principles; Greenbelt and Blackbelt training; Design-for-Six-Sigma, all stressed the importance of the "voice of the customer" and "no-value in rework". Hoshin stressed the importance of doing the job right the first time. Like you, I am amazed at the poor level of management that is more focused on meeting timelines and deadlines instead of focusing on the quality of the work. Too many coders today are more concerned with producing a quick fix. They are failing to take the necessary time to do proper research and questioning to avoid issues that result from poorly thought-out code. And as long as corporations/companies scale back on the wages, they will simply reap what they sow: buy cheap labor - get shoddy results.
OMG! I never had such training but that's what I've always pushed for. "The importance of doing the job right the first time" is incredibly important. One of my mantras on the subject is "Make it work (no faults, no missing features, no regression), make it fast (performs well), make it pretty (properly documented in the code and easy to maintain code), and it ain't done 'til it's pretty".
Thanks for making my day. Welcome aboard!
--Jeff Moden
Change is inevitable... Change for the better is not.
July 1, 2024 at 2:15 pm
Steve, I don't completely agree with you. Perhaps I'm misunderstanding you, however I see this as an iterative process. One gets the requirements from the customer, then writes the app as close to the requirements as possible. But what I've seen, especially the last 5 years or so, is the customer will look at the end result, then say, "Well, that's good and you've delivered what I asked for, but now I see it isn't what I want. I need you to change...". We don't really practice Agile, but effectively we practice a form of Agile as the customer realizes that what was delivered wasn't what they wanted. Sometimes we've misunderstood the requirements. And sometimes the app is exactly what they asked for, but then they realize they don't want what they asked for.
This then leads to either some rewrites, or it leads what, "Well, we can give you that in version 2.0.", which may or may not happen. It is impossible to get it right the first time. Especially when the user changes their mind after seeing the end result.
Kindest Regards, Rod Connect with me on LinkedIn.
July 1, 2024 at 3:07 pm
I find that some customers really know what they want, have an in-depth knowledge of their subject and can communicate their needs in a way that is an education. Getting it right first time is relatively easy when this is the situation.
For various reasons this holy trinity doesn't always exist. I worked on a project that was supposed to add personalisation to the company offering. It took quite a while for the business people tasked with driving the project to realise that they hadn't an agreed definition as to what personalisation was for the company. The need for personalisation was decreed from above. To this day I am not sure how personalisation could be applied to the product being offered.
One of the 1st projects I ever worked on was for someone needing to arrange their department budget. Everytime we thought we had grasped what they wanted a new layer in a bottomless pit of confusion was revealed. They just couldn't communicate effectively.
July 1, 2024 at 3:59 pm
I totally concur. Back in the late 90's and early 2000s Hoshin Principles; Greenbelt and Blackbelt training; Design-for-Six-Sigma, all stressed the importance of the "voice of the customer" and "no-value in rework". Hoshin stressed the importance of doing the job right the first time. Like you, I am amazed at the poor level of management that is more focused on meeting timelines and deadlines instead of focusing on the quality of the work. Too many coders today are more concerned with producing a quick fix. They are failing to take the necessary time to do proper research and questioning to avoid issues that result from poorly thought-out code. And as long as corporations/companies scale back on the wages, they will simply reap what they sow: buy cheap labor - get shoddy results.
I find myself somewhat frustrated the other way at RG, where we estimate we spend 10x time working on what to build than building. Feels slow at times, but I do get that we try to avoid rework and avoid making quick fixes or hasty decisions. I've learned to appreciate the pace, though it still can be frustrating at times
July 1, 2024 at 5:25 pm
Steve, I don't completely agree with you. Perhaps I'm misunderstanding you, however I see this as an iterative process. One gets the requirements from the customer, then writes the app as close to the requirements as possible. But what I've seen, especially the last 5 years or so, is the customer will look at the end result, then say, "Well, that's good and you've delivered what I asked for, but now I see it isn't what I want. I need you to change...". We don't really practice Agile, but effectively we practice a form of Agile as the customer realizes that what was delivered wasn't what they wanted. Sometimes we've misunderstood the requirements. And sometimes the app is exactly what they asked for, but then they realize they don't want what they asked for.
This then leads to either some rewrites, or it leads what, "Well, we can give you that in version 2.0.", which may or may not happen. It is impossible to get it right the first time. Especially when the user changes their mind after seeing the end result.
That's a big reason why people move to Agile/DevOps/et al. Because the customer doesn't always know what they want. Moving to small changes and small releases means that you target closer to what they want based on their feedback more often. And you reduce the amount of stuff that they don't use or don't like because it's not completely finished before you release it.
Rework isn't completely unavoidable, but there are patterns for performance, for the types of things your customers want/need, for cleaner code, that reduce debt and remove the need for rework. If they customer said they wanted a blue button and then says, no, red, that rework is unavoidable. If they wanted a button and your new dev makes one smaller or larger than other buttons and the customer wants it changed, that's silly rework, which is avoidable.
July 1, 2024 at 8:45 pm
When Agile is used for rapid feedback with responsive customers it can be an effective way to flush out system requirements. I've more often seen Agile used as cover for on the fly design by cowboy coders to simply get minimum functionality out the door. More often than not it comes back as very expensive rework. It can get even more expensive in organizations without solid design, coding, and testing standards and high turnover rates.
July 2, 2024 at 2:47 pm
Rod at work wrote:Steve, I don't completely agree with you. Perhaps I'm misunderstanding you, however I see this as an iterative process. One gets the requirements from the customer, then writes the app as close to the requirements as possible. But what I've seen, especially the last 5 years or so, is the customer will look at the end result, then say, "Well, that's good and you've delivered what I asked for, but now I see it isn't what I want. I need you to change...". We don't really practice Agile, but effectively we practice a form of Agile as the customer realizes that what was delivered wasn't what they wanted. Sometimes we've misunderstood the requirements. And sometimes the app is exactly what they asked for, but then they realize they don't want what they asked for.
This then leads to either some rewrites, or it leads what, "Well, we can give you that in version 2.0.", which may or may not happen. It is impossible to get it right the first time. Especially when the user changes their mind after seeing the end result.
That's a big reason why people move to Agile/DevOps/et al. Because the customer doesn't always know what they want. Moving to small changes and small releases means that you target closer to what they want based on their feedback more often. And you reduce the amount of stuff that they don't use or don't like because it's not completely finished before you release it.
Rework isn't completely unavoidable, but there are patterns for performance, for the types of things your customers want/need, for cleaner code, that reduce debt and remove the need for rework. If they customer said they wanted a blue button and then says, no, red, that rework is unavoidable. If they wanted a button and your new dev makes one smaller or larger than other buttons and the customer wants it changed, that's silly rework, which is avoidable.
Good point, Steve. Smaller iterations does make it possible to make any rework also smaller, because of being able to get that feedback as soon as possible. OK, I grant you that point.
Kindest Regards, Rod Connect with me on LinkedIn.
July 2, 2024 at 2:53 pm
When Agile is used for rapid feedback with responsive customers it can be an effective way to flush out system requirements. I've more often seen Agile used as cover for on the fly design by cowboy coders to simply get minimum functionality out the door. More often than not it comes back as very expensive rework. It can get even more expensive in organizations without solid design, coding, and testing standards and high turnover rates.
WOW, excellent point, Rob. Where I work, they've used Waterfall for many years. I wouldn't say we are trying to officially migrate to an Agile/DevOps approach, but it seems like we're unofficially moving in that direction. I suspect that we would be tempted to do a minimal viable product, in an effort to throw something quickly together. I've got to watch myself, to make sure I don't fall into that temptation.
Kindest Regards, Rod Connect with me on LinkedIn.
July 2, 2024 at 4:24 pm
When Agile is used for rapid feedback with responsive customers it can be an effective way to flush out system requirements. I've more often seen Agile used as cover for on the fly design by cowboy coders to simply get minimum functionality out the door.
This sums it up for me. The latter is an easy sell to decision makers because the message is fast and cheap. Someone told me that getting senior people interested in things that take a long time to do is almost impossible because those senior people won't be in the same positions in 18 months. They want something that screams "progress" during their tenure.
Neither waterfall or agile are the one universal answer to everything. Rob's comment nails the main reason for agile.
If you are building a known thing where the team is experienced in the business domain then you know your start and destination so waterfall is fine.
July 4, 2024 at 9:13 am
Rob Buecker wrote:When Agile is used for rapid feedback with responsive customers it can be an effective way to flush out system requirements. I've more often seen Agile used as cover for on the fly design by cowboy coders to simply get minimum functionality out the door.
This sums it up for me. The latter is an easy sell to decision makers because the message is fast and cheap. Someone told me that getting senior people interested in things that take a long time to do is almost impossible because those senior people won't be in the same positions in 18 months. They want something that screams "progress" during their tenure.
Neither waterfall or agile are the one universal answer to everything. Rob's comment nails the main reason for agile.
If you are building a known thing where the team is experienced in the business domain then you know your start and destination so waterfall is fine.
Spot on. I'll strongly second all of that. I'll also never go for "Fast and Cheap". Always include "Good" because, if it's not good, your customer will suffer and tales on the golf course will cost your company business. If you always concentrate on "Good", "Fast" and "Cheap" will start to follow automatically.
If it doesn't, you have the wrong people working for you or you might be in the wrong business. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply