Worse Before Better
-
Comments posted to this topic are about the item Worse Before Better
-
The problem starts with management. We live in a time when people have short attention spans and want to see results now. Imagine telling a top level manager that what looks like a simple code fix will take months? This because the symptom ended up pointing to a deeper issue that although hasnt broken yet, is a wreck waiting to happen.
You would probably not be taken at your word and would have to quantify your request (time and effort) and then no guarantees the task will be approved if the possibility that things might not fail is possible (though not realistic). This is not exactly motivational.
In the age of what you have done for me yesterday, it makes long term projects difficult to do right the first time.
----------------------------------------------------
-
There's a story about two people doing separate presentations to a government official using the same base statistics to argue contradictory cases. When challenged the 2nd person replied "Ah well, these statistics have been compiled to prove a completely different point".
This is where developing the skill of putting together a business case comes in handy.
- Will the problem get worse? Strong case for fixing
- Will it stay the same? Can you present a cost/time saving benefit?
- Will it dwindle over time? Forget it, you will be flogging a dead horse.
Money is the great lingua franca for organisations with a secondary language of time.
Lets suppose you have a team where there is a standard manual task that takes 15 minutes every morning. Over the course of a year you would be talking about 55 days a year at whatever the contract day rate is for a developer. From that you have a concrete monetary impact of that 15 minute manual task.
Does that manual task scale? What happens if you are a retail organisation with Black Friday looming. Does that 15 minute manual task get longer when customer usage gets heavy? As a manager one of your duties is to manage risks and threats. Being able to express the problem in terms of risk and threats and money helps towards the business case for a fix.
Is there agreement in the team that this manual process is a major headache for the team? If some of you think it is and some of you think it isn't then your manager will get mixed messages.
Lets suppose you have a build pipeline that takes 40 minutes to run and can run 4 builds concurrently. What happens if you have 6 developers trying to build? Does that mean that you have 2 blocked for 40 minutes at any one time? If you got that build time down not only would it save time for the waiting devs but also reduce the instances when the multiple builds compete for resources.
As Steve says, some things do require more resource than can be done with a quick fix. However, I know of occasions when senior devs have surreptitiously decided to fix a pain point and collaborated to get the fix done with the manager looking the other way. When part of your role involves attending meetings it is easier to argue that a main deliverable is "late" because of the amount of meeting attendance required rather than due to under-the-wire code fixes.
-
I have not held a lot of different IT jobs. Therefore, my experience may be tainted.
Having said that it is my experience that the short-term goals are either all that's consider or nearly all that's considered. Coincidentally, that situation is exactly what I'm experiencing now. I was hired, in part, to address an issue with an old Microsoft Access application that's vital to this business process. This app runs on MS Access 2007. I believe that it isn't necessary to have it on Access 2007, but it is believed that it is impossible to advance it to a newer version of Access. Therefore, without trying to update Access, they proceed to only use Access 2007 under the dread that "it will never work again!" if they update a copy of it. And there is no taking them out of it.
I am not an Access developer. I hate Access and never want to develop in it. Indeed, we've involved in re-writing it using newer technology, but for the time being the users are stuck at Access 2007. The backend is a SQL Server database, which is really where I come in.
Anyway, the problem is that occasionally the app will start moving slower. A lot slower. The users over the long years they've used it, have developed just one strategy to address this issue - like you said, Steve, reboot the server. The thing that frustrates me is that we never discovered what the root cause is. Instead, it is always, "Rebooting the server has always solved this problem before, therefore REBOOT THE SERVER!!!!!!!!!!!!!!!!!!!". I pointed out, as I have done so umpteen times before, that there are several other applications, two of which are also vital, with databases on the same database server. Doesn't matter to these users. Others must suffer in order get their application working again. So, once again, they rebooted the server, disrupting other systems to get their app working. And once again, whatever conditions there are that cause this problem are removed due to the rebooting of the server.
It is so frustrating.
Rod
-
I wound up in a highly similar position implementing 'immediate fixes' and never able to get to long-term solutions to stop all the 'immediate fixes.' It forced me into this assessment which helped to some extent:
Each issue causing us to do an 'immediate fix' fell into this assessment. It takes time, but I found it necessary. The mgmt team (i.e. those not in I/T line) did come around to understanding the long-term consequences. They didn't like it usually. But there was, from time-to-time, funding to address some of them.
-
I like that, @Wabmaster! I've downloaded your graphic and will review it.
Kindest Regards, Rod Connect with me on LinkedIn.
-
That is a great graphic. I'm going to save it as well.
And if you want to write up something on how you used it in a specific situation, I bet people would find that interesting.
-
Thx, Rod & Steve.
I'm attaching the xmind file here so you can manipulate it at will.
As far as previous use ... I would use the xmind file attached as a template ... creating a new version of it for every issue that warranted the assessment. All those data remain with my employer at the time.
One general story is we were supporting 1000s of customers online; registrations were accepted, build profile, all the usual stuff. Sometimes, and it wasn't known how, the GUIDs for new registrants would not be unique. This, of course, caused problems once the two same users had their data mixed (or worse). The quick fix was to inject a unique GUID (bad, I know, but that's what was done). This kept occurring for about 8 months, with an event every 2-3 weeks.
Finally, we were able to gain agreement for a sr. developer to review the code. With some over-the-shoulder monitoring by an unnamed individual, it was determined there were nested transaction-lock commands.
The assessment documentation helped us get all this in the open ... i.e. non-ending immediate GUID injections will likely cause an issue with a 'large client' down the road. That got their attention.
HTH
(I see the xmind file won't load here; let me know if you'd like it FTP'd or eMail'd somewhere else)
-
How much luck do you have actually getting people to fill it out? Some places respect process more than others.
- wabmaster wrote:
I wound up in a highly similar position implementing 'immediate fixes' and never able to get to long-term solutions to stop all the 'immediate fixes.' It forced me into this assessment which helped to some extent:
Each issue causing us to do an 'immediate fix' fell into this assessment. It takes time, but I found it necessary. The mgmt team (i.e. those not in I/T line) did come around to understanding the long-term consequences. They didn't like it usually. But there was, from time-to-time, funding to address some of them.
That's a really good chart. Thanks for posting it.
To the point of Steve's article, it's a shame that people don't do such a thing during development. Just change the left most block from "Problem Definition" to "Requirements Definition" and add a block on the very far right after all the good things you included have been done that says "Write the code to do it right the first time for the foreseeable future and scalability" and a couple of blocks to the right of that for things like "QA Tests the Hell Out of positive, negative, accuracy, and performance paths" and "UAT Intentionally Tries to Break Everything" and then you'll have a decent development plan, as well.
And, again to Steve's points of ...
- I think my experience has often been that organizations engage in short-term thinking.
- Good fundamentals make a difference in how we build and maintain systems.
Item 1 above is rampant in the world and I think that a large majority of people either never learned the importance of Item 2 above or they ignore it because someone else wants something real bad. Of course, that's the way why ultimately get it... real bad.
In a previous company I worked for, we changed the way we did things. We didn't release anything unless it was right and we were sure we weren't going to have to retouch the code for the foreseeable future for any reason. The also include peer reviews of both code and embedded comments. To make a really long story shorter, research for most changes dropped from 2 days to about 2 hours even for some of the larger changes. QA failures and the resulting rework virtually disappeared. UAT failures became unheard of. And complaints from customers totally tanked.
And a funny thing actually happened along with all that. We were actually able to put code out more quickly than ever because we weren't bogged down with rework.
Doing things right the first time just doesn't have any bad points once you develop the habit. And, you'll stop the revolving door for developers because they're going to be a whole lot happier and proud.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) - wabmaster wrote:
I wound up in a highly similar position implementing 'immediate fixes' and never able to get to long-term solutions to stop all the 'immediate fixes.' It forced me into this assessment which helped to some extent:
Each issue causing us to do an 'immediate fix' fell into this assessment. It takes time, but I found it necessary. The mgmt team (i.e. those not in I/T line) did come around to understanding the long-term consequences. They didn't like it usually. But there was, from time-to-time, funding to address some of them.
BTW... You should write an article about this with emphasis about "it takes time" but is so very worth it.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
ZZartin,
The process was something I created for myself, being in the position to influence those around me to supply the answers necessary to gain mgmt attention. I did share it with other managers (peers) but, as you surmise, they mostly think this is about process instead of fixing repetitive problems.
-
This is an excellent diagram. I saved a copy as well.
----------------------------------------------------
-
This was removed by the editor as SPAM
-
This was removed by the editor as SPAM
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply