|
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
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
