February 10, 2016 at 8:35 pm
Comments posted to this topic are about the item Reasonable Timeframes
February 11, 2016 at 3:04 am
I have found that it depends on whom the responsibility to fix it lies. Do they control a budget? Does it form part of what they have to report upwards? If no to either of these then expect it to drift to the bottom of the pile of work.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 11, 2016 at 6:45 am
Gary Varga (2/11/2016)
I have found that it depends on whom the responsibility to fix it lies. Do they control a budget? Does it form part of what they have to report upwards? If no to either of these then expect it to drift to the bottom of the pile of work.
Don't be too sure about the budget part either. Last year we put in to upgrade our current SQL Server 2005 to 2014. It got shot down because it was too expensive by the people who control the budget and now we've got an EOL deadline looming.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
February 11, 2016 at 7:08 am
In my experience on bigger systems, until people within the organization that are in the decision making seats with enforcement authority feel the pain of the systems inadequacies, other things will take priority. So, to get things done, the source of pain needs to be directed at the correct personnel.:-P:-P
February 11, 2016 at 7:15 am
They ten years was their estimate to replace the entire system. It shouldn't take even one year just to upgrade their network and patch security holes. Typical of most government agencies, they're primarily thinking about how to expand their general operating budget and creating jobs for years down the road... not fixing security issues here and now. Government IT is the last place you want to go looking for innovation or best practices.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 11, 2016 at 7:24 am
Never seems to be enough resources - time, money, software upgrades, etc. Focus on what's most important - a challenge itself. Creative thinking can sometimes provide better paths the solutions. Part of our job is to make sure those up the food chain recognize the resources required vs. the risks/consequences - often not in the job description.
February 11, 2016 at 8:23 am
Gary Varga (2/11/2016)
I have found that it depends on whom the responsibility to fix it lies. Do they control a budget? Does it form part of what they have to report upwards? If no to either of these then expect it to drift to the bottom of the pile of work.
I've also found that it depends upon whether or not the users or managers can see it. For example at my old job I saw two really bad database design issues. I lobbied for years to get them fixed and finally, with the help of people on this website, I got one of them fixed.
But when I was done with it the manager couldn't see any difference, so she didn't want me to fix the next done. They're still living with that problem today.
Kindest Regards, Rod Connect with me on LinkedIn.
February 11, 2016 at 9:03 am
Rod at work (2/11/2016)
Gary Varga (2/11/2016)
I have found that it depends on whom the responsibility to fix it lies. Do they control a budget? Does it form part of what they have to report upwards? If no to either of these then expect it to drift to the bottom of the pile of work.I've also found that it depends upon whether or not the users or managers can see it. For example at my old job I saw two really bad database design issues. I lobbied for years to get them fixed and finally, with the help of people on this website, I got one of them fixed.
But when I was done with it the manager couldn't see any difference, so she didn't want me to fix the next done. They're still living with that problem today.
Far too common. It happens with cars too. No one believes the mechanic until they are waiting for the recovery vehicle at the side of the road.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 11, 2016 at 9:45 am
Eric M Russell (2/11/2016)
They ten years was their estimate to replace the entire system. It shouldn't take even one year just to upgrade their network and patch security holes. Typical of most government agencies, they're primarily thinking about how to expand their general operating budget and creating jobs for years down the road... not fixing security issues here and now. Government IT is the last place you want to go looking for innovation or best practices.
I have to disagree with you, Eric. While I'm sure the generalization is true in some places, it hasn't been in the places that I've worked at. I've spent pretty much my entire career in government, at one level or another, since 1988. I've seen some cool tech implemented, I've seen some good preemptive work, including unplugging our border router's external connection when I Love You hit. Our upstream connection, the City, got clobbered, we did not.
Best practices? Well, I can't attest to that. Budgets are always pretty tight, and it's hard to work against inertia to get new methodologies implemented. I think it's a case of 'win some, lose some'.
I agree: their network should have been patched within a year. All of the most grievous holes should have been propped up, if not completely repaired, within a year. It definitely takes a long time to do major change, even with buy-in all the way to the top.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
February 11, 2016 at 10:55 am
Some years ago the company I was working for then brought in a new support manager whose experience was in engineering manufacture but not IT. He devised a new system for categorising faults based on their priority from Critical down to Trivial. These were reviewed every week in a Monday morning meeting where he defined the order faults/bugs were to be tackled. After some months some of us (bug fixing taking around 20% of my time) asked how much time needed to pass before a trivial bug was upgraded. His view was never. After he had been there some more months major clients (major financial institutions and others) started shouting loudly about the trivial bugs and work arounds. It was not long before he joined the job market!
Many factors come into deciding timescales!
February 11, 2016 at 12:11 pm
mjh 45389 (2/11/2016)
Some years ago the company I was working for then brought in a new support manager whose experience was in engineering manufacture but not IT. He devised a new system for categorising faults based on their priority from Critical down to Trivial. These were reviewed every week in a Monday morning meeting where he defined the order faults/bugs were to be tackled. After some months some of us (bug fixing taking around 20% of my time) asked how much time needed to pass before a trivial bug was upgraded. His view was never. After he had been there some more months major clients (major financial institutions and others) started shouting loudly about the trivial bugs and work arounds. It was not long before he joined the job market!Many factors come into deciding timescales!
It sounds like he should have focussed on the "trivial" bugs, while they were still seemingly trivial. A trivial bug allowed to linger long enough will become a critical bug. The same can be said for security vulnerabilities; it starts as something simple, like a single miscoded line of code which should have been caught by a code review or testing. Once in production it results in a buffer overrun. Time passes and no one notices at first, but then eventually someone does, and then the exploit gets advertised across the web. In the interim the issue may have been raised to the attention of the development team, but a malicious hacker beats them to the punch and uses the exploit to break into the system.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 12, 2016 at 4:10 am
I sympathize with those people dependent on mainframe systems
A little rant... I worked on mainframe systems, and they are documented to the same standards as systems written for Windows or Linux: sometimes good, sometimes bad. They are no harder or easier to change than systems written for Windows or Linux. No special sympathy is needed because the problems are the same for all applications. ...end of rant.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
February 12, 2016 at 4:10 am
An Audit failure should be treated just the same as any other bug. It needs to be assessed and prioritised. Some bugs may get fixed almost immediately, while it can be reasonable to leave others to be 'fixed' when the application gets replaced. No piece of software is perfect, and all systems have a backlog of technical debt.
An Audit failure may have legal and reputational issues associated with it, but this is no different to any other type of bug, merely that these issues are highlighted along with the bug. If a legal issue is that a licence to trade may be revoked or staff become liable to prosecution, this should affect the priority for fixing the problem, but the same issues can arise from a bug found from any other source.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
February 12, 2016 at 9:01 am
EdVassie (2/12/2016)
I sympathize with those people dependent on mainframe systems
A little rant... I worked on mainframe systems, and they are documented to the same standards as systems written for Windows or Linux: sometimes good, sometimes bad. They are no harder or easier to change than systems written for Windows or Linux. No special sympathy is needed because the problems are the same for all applications. ...end of rant.
My apologies. I didn't mean to disparage the mainframe as a resource. It's great, overall, reliable and solid.
My comment was more on the skills being lost, few choices of resources, and the constraints of making changes, often because a change must be solid.
March 8, 2016 at 6:45 am
Steve Jones - SSC Editor (2/12/2016)
EdVassie (2/12/2016)
I sympathize with those people dependent on mainframe systems
A little rant... I worked on mainframe systems, and they are documented to the same standards as systems written for Windows or Linux: sometimes good, sometimes bad. They are no harder or easier to change than systems written for Windows or Linux. No special sympathy is needed because the problems are the same for all applications. ...end of rant.
My apologies. I didn't mean to disparage the mainframe as a resource. It's great, overall, reliable and solid.
My comment was more on the skills being lost, few choices of resources, and the constraints of making changes, often because a change must be solid.
EdV was right to challenge the original statement, and his "rant" is more of a well-balanced and accurate statement than a rant. But I think your respinse has gone too far from the comment in the editorial towards an opposite extreme! Some mainframes were indeed painful to live with (as were some mini-computers, some desk top computers, and so on). If you think all mainframe software is great, overall, reliable, and solid you've obviously never worked with early IBM 360 systems or the various similar (almost the same same non-priv instruction set, but sounder non-priv architecture from a security point of view) systems produced by RCA, English Electric and others.
A lot depends on which mainframes you look at. In some cases fixes to OS and to middleware and to basic development tools tend to come quickly, especially if customers complain about problems - and even "trivial" things get fixed pretty fast. In other cases, new features arrive quickly but remain unfixed for far too long. In yet others new features come very slowly and problems don't get fixed quickly either. That spectrum seems to me to be very much like what happens with non-mainframe systems.
Tom
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply