|
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.
|
|
|
|
|
|
Ravi Bhavnani wrote: Have you used Lenny
No, but I just might!
You made me think of one of my favorite old phone pranksters: Willie P. Richardson[^]. This guy was hysterically funny.
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.
|
|
|
|
|
|
I'm working on an extensible code / text editor based on SharpDevelop, and I would normally use WinForms, but I have decided to use WPF for this, mostly to learn how it works.
I also found my SATA to USB adapter cable so I was able to connect my old hard drive and get the source code I needed off of it.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
|
I think of WPF more as "twisty little passages"
|
|
|
|
|
For background, I have noticed that in stable systems, most code "fixes" are like 1-2 lines of code. It was an edge condition, or something nuanced somewhere.
For years, while getting new programmers up to speed, I told them that when the majority of their code changes were small changes (naturally), that they could use that as a marker of competency. I would have them track the number of lines of code the changed to fix issues.
I have nothing except 30+ years of experience telling me this is true.
So, I am curious if others experience this same thing? (Early on in a project, fixes require much heavier sets of changes, and as it gets ready to go live, the changes are tiny by comparison)...
Thanks in advance.
|
|
|
|
|
No, because by now, I've overflowed the 64-bit integer, and they haven't invented the 128-bit integer yet.
I suppose I could switch to a decimal type to keep count...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: they haven't invented the 128-bit integer yet.
Well, there is BigInteger Structure (System.Numerics)[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Maybe you should resort to floating point numbers.
|
|
|
|
|
It only seems obvious to me. If you need reams of new code to fix something, then clearly something was not well thought-out if not missed altogether.
I wouldn't necessarily link this with competency, but perhaps experience.
|
|
|
|
|
How exactly are you separating competency from experience in this case?
If experience teaches you to do it one way, I believe that increases competency. And perhaps I simply used the term interchangeably (and I kinda did).
Writing lots of code in the beginning is fine. It's our job. But having to rewrite a lot of code later is the issue I believe reduces later with experience as well as when a product stabilizes.
|
|
|
|
|
Kirk 10389821 wrote: How exactly are you separating competency from experience in this case?
Some people only learn from experience (which can be costly). Others simply have a knack for putting together good code even though they might not necessarily have much (or as much) experience.
|
|
|
|
|
I think you would have to define what you mean by a "fix", because if by "fix" you mean something that takes two lines of code then there is something of a tautology in the definition.
I am currently working on something where the "fix"(and it is a fix as it's a change so that the system models data consistently) is going to probably be a change to the fundamental manner in which a huge piece of software works - so I am hoping that we decide not to fix it.
That said I think I get the gist of what you are saying along the line of - extend don't modify.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
You have an interesting case. How close are you to release, or how long has this been released for?
|
|
|
|
|
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
|
|
|
|