July 18, 2016 at 9:11 pm
Comments posted to this topic are about the item Scary Deployments
July 19, 2016 at 12:49 am
This situation destroys trust between IT and business people. The question "Why don't you know how to alter the system you wrote?" Is a hard one to answer.
July 19, 2016 at 12:50 am
I'd say that developers are only afraid to touch old systems because they know they will not be allowed time to refactor or remove technical debt because there is no business case and hence no money to do it but yet extra functionality and tweaks will be expected to be made.
July 19, 2016 at 6:02 am
peter.row (7/19/2016)
I'd say that developers are only afraid to touch old systems because they know they will not be allowed time to refactor or remove technical debt because there is no business case and hence no money to do it but yet extra functionality and tweaks will be expected to be made.
This is the kind of system I've often ended up with, and the good news is that you can turn it around... with your manager's support. Without that, then, like one place I worked, you have to move on (we called it "technical differences": they would not have any primary/FK constraints because it gave db errors in their buggy app, but were surprised that it was impossible to work out how many advanced sales they had since the rep-to-sales-area relationship - among many - had null/duplicate reps and null/duplicate sales areas) .
It means that every fix I carry out takes longer, as there's considerable refactoring involved - but I'm selling it as it will mean quicker changes & improvements later. Getting the user on-board, (and delivering their priorities too) is also important as, without testing, your deployments can still be perilous. Controlling your versions properly so you can respond quickly when things are wrong, helps. Also, each deployment, tell the manager and users what changes there are, so they know how much hard work you've put in (the content should not be a surprise as they've tested it...) . I'm sure I've missed stuff out, but, in short, I like turning the product around and having happy users!
PS I'm still hoping that this logic will earn me a million one day: the best way to earn a higher salary is to go to work for a badly managed company with lots of legacy code :unsure:
July 19, 2016 at 6:52 am
I was listening to a web developer talk about some fundamental changes in a web platform. In this case, an older system was being replaced completely with a new one, and as one of the reasons, the developer showed some typos that had existed on the old site for years and hadn't been fixed.
So, what do they mean by "typos" here ?
There have been occasions where I've made touching, or even learning, the internals of an old platform a very low priority, because a new platform was under development.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 19, 2016 at 7:00 am
David.Poole (7/19/2016)
This situation destroys trust between IT and business people. The question "Why don't you know how to alter the system you wrote?" Is a hard one to answer.
I would say that it is more indicative of the lack of trust in the first place, and these kinds of statements make the situation worse. I would seriously look for another supervisor if I heard that out from management.
I am one who will often jump in where others hate to. But I also will tell those above me that there are risks and that the amount of time to make changes may not be trivial. I had to maintain a form type application driven mainly by a 21K line if/else conditional. I was quite happy and relieved when that was put to bed.
I will also say that one person's great code is another person's misery.
July 19, 2016 at 7:31 am
David.Poole (7/19/2016)
This situation destroys trust between IT and business people. The question "Why don't you know how to alter the system you wrote?" Is a hard one to answer.
The problem is explaining that 'you' doesn't mean the current staff. It was someone who created the system years ago and has since left the company. The replacement they trained also left the company. What's left is a working legacy system with little or no documentation and critical functionality.
When there's a replacement in the works there's no real reason to touch a working system that everyone knows and knows the oddities of using it. There's a big risk of fixing A only to break G through S because there's no way to tell what's dependent on what without spending more time than it's worth to transpose some letters.
Sometimes there's good reason to be afraid to meddle with code. Sometimes there's not. The trick is knowing which is which.
July 19, 2016 at 7:52 am
Exactly--this is a management problem. What's scary is not so much the software itself but not knowing how long it might take to understand and fix and test it, and not being able to get management commitment for a complete rewrite. If there are tight budget and schedule constraints, maybe it needs to be treated as a black box whose functions are gradually subsumed by new modules until the black box can be decommissioned.
July 19, 2016 at 8:27 am
Eric M Russell (7/19/2016)
I was listening to a web developer talk about some fundamental changes in a web platform. In this case, an older system was being replaced completely with a new one, and as one of the reasons, the developer showed some typos that had existed on the old site for years and hadn't been fixed.
So, what do they mean by "typos" here ?
There have been occasions where I've made touching, or even learning, the internals of an old platform a very low priority, because a new platform was under development.
I think the implication is they were so concerned about changes they would not even make minor edits to correct blemishes in the UI.
July 19, 2016 at 9:13 am
Man, can I ever relate to this article. Last year I was told to fix a legacy application that hadn't worked for a year or two. This was close to when I first came to work here. One of the hard things about the project is the source code wasn't in source control. In fact, it wasn't anywhere at all. I had to put in a help ticket to have the original developer's machine be restored from backup so I could piece together the code as best I could. That took 4 to 6 weeks to do, because the guy didn't leave his code in one location, but scattered it all over his HD. Fortunately, the application is simple; only about 10 web pages. The database is small, only about a dozen tables, and that's including the lookups. But its a mess. I think this has to be one of the worst architected apps I've seen, starting with the database. I remember bringing this up in the forums here; none of the tables have a primary key. None of the tables are related to any other table. For all intents and purposes, they're just flat files housed in a database. And the application itself has 8 separate projects in it, which I've no idea why the guy did that. At the heart, it isn't a complicated project, so why did he put in all of this excessive baggage? And what in heck does it do? The originally developer left this state agency a few years back. I've learned that he went to another state agency, in the building next door. But I'm under strict instructions not to talk to him, because that would involve us having to pay them a fee. I think peter.row put it best when he said that from management's point of view, there's no business case to refactor or remove technical debt. In fact peter.row, I didn't realize what I'd done until I read your comment. Without realizing it, I've enabled management to leave this software that runs via witchcraft, alone. Because I hobbled enough of it together so it could continue to work. I'm now kicking myself.
Early on in the process of working on the app I asked to re-write it, starting with the database. I was told not to do that. To only change the minimum of what needed to be changed. So that's what I did. It's still a Rube Goldberg assortment of software doing God only knows what, but as a side effect it does what's required.
Kindest Regards, Rod Connect with me on LinkedIn.
July 19, 2016 at 9:35 am
David.Poole (7/19/2016)
This situation destroys trust between IT and business people. The question "Why don't you know how to alter the system you wrote?" Is a hard one to answer.
As an IT manager, this made me question developers' competence.
July 19, 2016 at 9:37 am
Eric M Russell (7/19/2016)
I was listening to a web developer talk about some fundamental changes in a web platform. In this case, an older system was being replaced completely with a new one, and as one of the reasons, the developer showed some typos that had existed on the old site for years and hadn't been fixed.
So, what do they mean by "typos" here ?
There have been occasions where I've made touching, or even learning, the internals of an old platform a very low priority, because a new platform was under development.
Literals typos on some pages (Web). I'm not sure if these were includes, but somehow hard coded, not database driven, content.
July 19, 2016 at 9:39 am
We got into a situation where we had to create an MS-Access application for a business need in a hurry. The application was created and supported by one person for a couple of years. Then this person had to go on medical leave and only came back a couple of times. The application was poorly documented and the person who created it was the only person (in IT) that understood the business process. So when they left for good, the rest of the IT staff (only a few had any MS-Access experience) had to provide support for this application. And as saying goes 'If it aint broke, don't fix it'. So we did not want to 'break' the application by making changes.
We have also have users outside of IT develop their own MS-Access applications and then want us to fix or modify the application at a later date. That is something we really try to avoid.
July 19, 2016 at 9:55 am
Steve Jones - SSC Editor (7/19/2016)
David.Poole (7/19/2016)
This situation destroys trust between IT and business people. The question "Why don't you know how to alter the system you wrote?" Is a hard one to answer.As an IT manager, this made me question developers' competence.
As a developer this made me question managers' competence;-).
When the staff is cut with no turn-over, projects are "defunded", and developer guidance is "make the minimum changes" you end up with a Tar-Baby no one want to stick their fingers in.
July 19, 2016 at 9:58 am
Steve Jones - SSC Editor (7/19/2016)
Eric M Russell (7/19/2016)
I was listening to a web developer talk about some fundamental changes in a web platform. In this case, an older system was being replaced completely with a new one, and as one of the reasons, the developer showed some typos that had existed on the old site for years and hadn't been fixed.
So, what do they mean by "typos" here ?
There have been occasions where I've made touching, or even learning, the internals of an old platform a very low priority, because a new platform was under development.
Literals typos on some pages (Web). I'm not sure if these were includes, but somehow hard coded, not database driven, content.
So, we're just talking about content here, not programming? For example, instead of a link saying "Recent Posts", it would say something like "Recent Pests", and the developers we're afraid to change it?
That type of think should be a meta data change or simply a modification by the website's content team. That doesn't even come close to what I'd consider a scary IT deployment.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 1 through 15 (of 37 total)
You must be logged in to reply to this topic. Login to reply