|
The application has been around for some 12 years and has had layers upon layers of code built within it.
This is why some small changes can be so difficult on the system as each small change can require a lot of investigation first.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
As an addition to what Dandy wrote:
I would see fixes that requires just a few rows, as competence in whoever wrote the previous code.
|
|
|
|
|
Exactly what my experience has been.
There are systems/programs that you pickup and say Ughhh...
And there are times when a wholesale rewrite might be in order.
we all remember that OLD example:
If X = 1 then Counter001 = Counter001 + Data;
...
If X = 103 then Counter103 = Counter103 + Data;
And you are ask to add another counter... For the love of all that is good, PLEASE consider refactoring with an array.
And this is the EXCEPTION that proves the rule. The simplest change was fine at first. But at some point, the code was NOT designed properly originally, and requires some surgery.
This tends to happen with Poorly written code, or a very immature product. It certainly should not be happening just before a code freeze and going live, or immediately after going live.
|
|
|
|
|
Yes.. and no. It depends on the bug. I agree that a lot of bug fixes are just a few lines of code to handle some nuance. However, I've also run into bugs that took pages of code to fix. Not because the system was poorly designed, but because the information needed to handle the nuance wasn't available and took a bunch of code to make available.
|
|
|
|
|
patbob, in this case, I am curious. Why was the required contextual information unavailable?
Should it have been in the first pass of the design? Was this a new requirement, or a deep nuance that was not clear until the code was actually used?
Next, given what you know today, and looking to implement the code again... Would you have to do all of that work again?
Finally, what is the status of the code: Beta, Released... Ancient?
|
|
|
|
|
Kirk 10389821 wrote: Why was the required contextual information unavailable? Should it have been in the first pass of the design? Was this a new requirement, or a deep nuance that was not clear until the code was actually used?
Because we hadn't realized we'd need to make a decision based on that info. It was a corner case of the problem domain that few of our customers ever got into, so yeah, I'd classify it as a subtle nuance. And no, it wasn't some change in the requirements on the system, just an ordinary bug.
Kirk 10389821 wrote: given what you know today, and looking to implement the code again... Would you have to do all of that work again?
Yes. Although when we do it again, I hope the design is redone to make it easier to extract that information out of the graph, although I doubt it since we had to extract a very special subgraph to run the analysis on. The bulk of the work to fix the bug, was to extract that subgraph. Once we had that, walking it to solve the bug was fairly easy.
Kirk 10389821 wrote: What is the status of the code: Beta, Released... Ancient?
At the time of this bug, the code had only been in production for a few years. Enough time it'd seen a bunch of use from customers, very few of which ever ran into this case.
One could always say that we hadn't done sufficient analysis, but I have a hard time thinking that, given how subtle it was, and how few customers it actually affected.
|
|
|
|
|
Kirk 10389821 wrote: that they could use that as a marker of competency.
I think, rather than a metric for competency, it is a metric for two sides of the same coin -- the "head" side is it was just a stupid bug in an otherwise well designed application. The "tail" side is that it was just a stupid bug in a poorly designed application. The difference is that for a head side fix, the bad code is corrected. For a tail side fix, the fix is usually wrapped in an "if" statement, like "if we're working with this data from that source, then do foo, otherwise do bar" which is indicative of someone else's incompetency.
But I might be myopic here, as I recently had to code a tail-side fix because the library being used by one product had the mailing address and physical address in the correct fields, and same the library being used by another product was giving us the mailing address and physical address in the opposite fields, because somewhere along the line the DB fields for "address" and "mailing address" had been re-purposed incorrectly.
The fix was a couple lines of code but definitely didn't reflect my competency as I was dealing with someone else's incompetency that I couldn't fix.
|
|
|
|
|
Marc, if you could have fixed the ACTUAL Errant code...
How big of a change would it have been?
I call this working around library bug. It usually happens early in the process, fortunately.
These kinds of changes can suck the life out of you if they happen often enough.
|
|
|
|
|
Do they also keep track of how many bugs are introduced by the 'fix'? 
Kirk 10389821 wrote: marker of competency
Competency of who, the 'fixer' or the original author? (for me, as a solo dev, I'd be both I guess)
Kirk 10389821 wrote: So, I am curious if others experience this same thing?
Yes, for the most part, but I've got a 20 y/o legacy distributed desktop app that still sees regular maintenance.  'Fixes' are really only required to handle the bugs introduced by that last feature enhancement/addition! It's in the slow and painful process of getting migrated to rewritten in .Net.
Just an unrelated comment: I've been trying to formulate this response for about 4 hours now...write a line, phone rings...an hour and a half later, write another line, phone rings...half and hour later, etc...hang on, that's my bil with the daily commiseration session...nevermind...sending anyway!
"Go forth into the source" - Neal Morse
|
|
|
|
|
Quote: Do they also keep track of how many bugs are introduced by the 'fix'? Laugh |
LOL. Since we always tend to do code reviews... We don't get a lot of those.
The one man shop... This is why I keep email notifications off.
Look into a pomodoro timer. Turn the phone on silent (not even virbate), work for 25 minutes ( a cycle ), and then check things when you get out to return calls.
DO NOT let the phone steal your focus... All of our developers are the last people to get a phone call. Focused time is way too precious. Good luck!
|
|
|
|
|
Kirk 10389821 wrote: have nothing except 30+ years of experience telling me this is true.
Well I disagree with you, my 30+ years of development tell me that smaller fixes are a natural progression of a maturing project and not a valid measure of competency.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
MyCroft,
So, you have never seen a new programmer tackle a problem in a mature product, and end up creating the next 2-3 bug fix requests? Do you work with new developers much (just curious since we are on the opposite side here of opinion and experiences)
And yes, the title mentions tracking completion (near maturity) by the breadth of changes required in fixes... That's half of it.
I REALLY appreciate your feedback... Thanks!
|
|
|
|
|
Kirk 10389821 wrote: Do you work with new developers much
Ah that may be the difference, I work with a very mature team of 5 devs who have been together for some years. I find large changes are generally due to either the business not knowing what they want or a misinterpretation by the developer of the requirements.
Bugs and the time spent nailing them should be a reducing requirement, I do not consider the time spent eliminating bugs as a measurement of competency. If you are getting towards the end of a project and there is a major piece of rework required either you f***ed up or the business f***ed up.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft,
That is clearly a factor in your experience. I think it explains it.
When you work with mainly competent and experience people, you don't have the same types of bugs.
Like something that synchronizes data for a group, that is NOT protected from someone synchronizing their own data while the larger process is running (causing duplicate adds, for example). Just knowing to think in those terms comes from experience. Understanding how long things WILL take in production vs. on your local machine, etc.
Or that they don't notice that if it takes 30 seconds to test one record in a process... How long will it take when the expected HUNDREDS of records hit?
An example of a one line fix was: Don't sync closed items. Massive speed up, as closed items did not really exist in the first implementation, but 2 years later, were the majority of records.
|
|
|
|
|
When my girlfriend tried to make me have sex on the roof of her Honda Civic I refused. If I'm going to have sex, it's going to be on my own Accord.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
What's the Mazda with you? I doubt you can a Ford to turn her down - later she might be tired.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
With your Mini you shouldn't be picky and just Ram her 
|
|
|
|
|
What ever happened to "not posting stuff you wouldn't want your kid sister to see" herein?
@marc-clifton ???
The best way to improve Windows is run it on a Mac.
The best way to bring a Mac to its knees is to run Windows on it.
~ my brother Jeff
|
|
|
|
|
MacSpudster wrote: What ever happened to "not posting stuff you wouldn't want your kid sister to see" herein?
Can't speak for the other guys, but I for one do not have a sister.
Sometimes the true reward for completing a task is not the money, but instead the satisfaction of a job well done. But it's usually the money.
|
|
|
|
|
MacSpudster wrote: not posting stuff you wouldn't want your kid sister to see
That won't get you very far in my family. I have three sisters younger than me. All have heard (and sometimes use) the "seven words that should never be heard on television".
I do agree that this was a little over the line for the Lounge.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
True story: When my father-in-law passed away several years ago, he had left his Honda Accord to his eldest daughter. For the month (June) before she could arrange to come get it, it was parked in our driveway. One particularly hot afternoon, the wife had arrived home from a trip so I walked out to welcome her home and carry the bags. As we passed the car, she pointed to the ground behind the car where the chrome model placard lay and asked what happened. I said very dryly 'it appears to have fallen off of it's own Accord.'
"Go forth into the source" - Neal Morse
|
|
|
|
|
Equally true story: My first new car was a 1985 Accord. My wife and I were driving to see her family, and passed the exit to Marysville(*), Ohio. I told Mrs. Wife "Be careful; the car might take that exit of its own Accord."
(*) Accords were built in Marysville at the time.
Software Zen: delete this;
|
|
|
|
|
But the important question...how many seconds until she got it?
"Go forth into the source" - Neal Morse
|
|
|
|
|
Not many - the lady's pretty sharp.
Software Zen: delete this;
|
|
|
|
|
It's much better whilst laying out on the Riviera.
Sometimes the true reward for completing a task is not the money, but instead the satisfaction of a job well done. But it's usually the money.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
