|
Thank you for this. Now added to my playlist.
|
|
|
|
|
Also added. Thanks for pointing it out. Reminds me a bit of Cosmo Sheldrake (who I'm certain I mentioned before).
|
|
|
|
|
Can totally hear it too, nice one! 
|
|
|
|
|
|
Interesting, I don't think I've (knowingly) heard the genre before!
It all sounds a bit alike though... Not something I can listen to for two hours 
|
|
|
|
|
Tonight is the first I've heard it, too. Some of the 'destruction' music I really liked. But I can't argue that a lot of it was alike. 
|
|
|
|
|
The music sometimes reminded me of Ayreon, which you might like: Into The Electric Castle[^]
It's melodic metal from The Netherlands and I don't really like it, but it's also story-driven and the artwork is pretty steam punk 
|
|
|
|
|
A lot of the last year, I have been gutting legacy code from our app and rewriting from scratch a stupendous marvel!
-- Except --
Due to [legal stuff redacted] we need to handle the legacy data structure. This means at the back all the bd data needed to be preserved and it restrained the new functionality.
I have ticket to add back in some intentionally omitted elephantine functionality. You cannot believe the joy I had in closing it with a comment of "Not going to happen! We've removed it as it should never have been there, there is a better and EASIER way to do it now!"
The ticket has been reopened as "the user doesn't want to change their workflow"...
veni bibi saltavi
|
|
|
|
|
Quote: rewriting from scratch a stupendous marvel!
Which is, often, quite satisfying …
Quote: "the user doesn't want to change their workflow"
Which, often, translates into: someone makes his/her living maintaining that workflow …
Espen Harlinn
Senior Architect - Ulriken Consulting AS
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.Edsger W.Dijkstra
|
|
|
|
|
Espen Harlinn wrote: Which, often, translates into: someone makes his/her living maintaining that workflow …
Agreed. I've experienced numerous situations where one or more people resist change as the old way of doing things means job security.
One program we replaced featured a 2-digit code field with hundreds of potential values. One user had the codes memorized and could fly through data entry, while everyone else could remember the commonly used codes but was hampered by having to look up any of hundreds of uncommon codes. [The old application was written in Clipper, so the "GUI" was text based.]
That one user was threatened by the idea that, using the new application (which had a lookup mechanism for the codes), anyone could be trained quickly to do that job. I was told this resulted in a number of ugly shouting matches between that one user and various managers.
|
|
|
|
|
I think we've all seen this pattern.
Now, I love keypunch fields like that, and in the past, I've only made one modification.
I allow the user to hit a key (? or F3, etc), while on that field, to open up a lookup dialog, and search by name, or scroll... And select.
The best of both worlds. The old user cannot complain, because it does not affect them!
The new users get trained faster/better.
For the record, this should have been designed INTO the product in the first place, in general.
Nobody should have to remember "codes"
|
|
|
|
|
Kirk 10389821 wrote: For the record, this should have been designed INTO the product in the first place, in general.
Nobody should have to remember "codes"
You've obviously never worked on some of the old mainframe systems.
When your paying big dollars per KB, you're not going to waste it by putting in "helper" type messages when a piece of printed paper with values for lookup codes will do.
Many of the "codes" we see in modern systems are often a legacy from the time when every bit was precious.
|
|
|
|
|
Actually, I did work on legacy systems.
And whenever we moved them to Clipper (oh, the days), or some other technology,
we implemented the lookups.
Not much I could do with the COBOL, other MANY of the 3270 terminals had extended function keys, and second terminals to assist in the lookups. Sometimes on another screen/window. And then back. It wasn't the best, but it beat memory and the often TAPED OVER PAPER all around the keyboard.
In fact, if you look HARD enough at an HTML FORM, and a mainframe screen. You wig out because it's so similar. Fields defined, the form is defined, the update is pushed back with the field values encoded, but the rest of the screen not sent. It's crazy. Everything OLD is new again. LOL
|
|
|
|
|
this stresses the importance of having a user requirement document/functional design documents signed off by the user/department of the business before the system is designed or changed.. i had a case where the user just had a user manual with screen shots of the old program and said they new program needs to have all this...it did'nt end well...
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
I never understood these rewrites that should basically produce the exact same application 
It would probably be best to sit down with the user and show them how it's done now.
In fact, this request might not even come from a user, but from a manager who thinks their employees should not lose time/make mistakes learning a new system because it would look bad on them.
Or maybe a manager with no imagination who thinks the current system is the best and/or only system that works for their department.
Or it may come from users who are afraid they'll not understand the new system and it could cost them their job.
In my experience, this kind of behavior is usually not bad intent, but lack of knowledge or fear of the unknown.
That's why it's so important to involve users early on.
And sometimes, just sometimes, the users really have some very specific functionality or workflow that we developers and/or business analysts missed and the new system would make their job harder or take longer. Nah, who am I kidding? We're perfect 
|
|
|
|
|
In our case one of the main reasons for the rewrite is to move to newer technology in order to move to different more cost effective hosting - Windows Server to Linux. Also for easier maintainability going forward. The new system isn't an exact copy of the old, but familiar enough for users to find their way.
|
|
|
|
|
Jacquers wrote: more cost effective hosting
Must be some cheap hosting if it outweighs the costs of a rewrite 
|
|
|
|
|
There are a couple of factors involved. Windows vs Linux. Our 'parent' company overcharging us imo and I think a developer's standby / salary is included in the hosting costs we pay, which drives it up further. So while the rewrite is expensive and a pain atm it will probably be recouped within 2 years. Financially it makes sense, it just sucks for us devs who are being pushed / forced to complete it and deploy it before it's really ready for production.
|
|
|
|
|
Sander Rossel wrote: It would probably be best to sit down with the user and show them how it's done now.
In fact, this request might not even come from a user, but from a manager who thinks their employees should not lose time/make mistakes learning a new system because it would look bad on them.
Or maybe a manager with no imagination who thinks the current system is the best and/or only system that works for their department.
Or it may come from users who are afraid they'll not understand the new system and it could cost them their job.
There is another (but related) scenario that I have seen myself: Both users and managers may well recognise that there are other/better ways to do things but that some of these ways might actually improve efficiency. That can be a problem.
An improvement in efficiency sounds great for the business but:
(a) For many employees "greater efficiency" quite literally means "no job".
(b) Managers at certain levels may be rewarded for improving efficiency by losing out on power/empire or even losing their team entirely as it is redistributed to other managers. They can improve themselves right out of their own job.
Rightly or wrongly, a lot of businesses will in effect punish both management and employees for improving things for the shareholders.
As I mentioned above, I've seen this myself: I was collecting user requirements for an order-taking/processing system and I could see exactly what needed to be done. I was enthusiastically describing how the system could eliminate certain manual steps. Then I noticed I was getting some unpleasant looks. Whoops... I was describing classic "efficiency improvements" which directly translated into lower head count. Some of the staff would be literally redundant. And their manager would have reduced responsibility.
As the PHB once said (or something like this): "It's going to take a strong team to succeed. Specifically a much smaller team."
|
|
|
|
|
You're just selling it wrong 
I hear what you're saying though and it can be a real issue.
I always try to make myself redundant.
If I'm redundant I've done a good job and made or saved (my employer) lots of money.
Any employer should see value in such an employee.
The issue here, of course, is the people are not making themselves redundant, they're made obsolete 
|
|
|
|
|
agree 100%
The cream of the employees are often given opportunities to move UP in the company. We had a young man who did just that with these kinds of improvements, and since it was an improvement like these, that allowed him to replace a much more experienced user, he was the one bringing suggestions to us.
Like: guys, I love having 2 monitors, but if I had a third monitor, I could be stationed at the Front Desk, and answer the phone, and sign for the packages. The next day, I put a third monitor on his machine, and moved it to the front desk. [we were a small startup, couldn't afford a receptionist, but needed one]
Yes, some employees will be let go, and HOPEFULLY they learn to step it up at their next position...
|
|
|
|
|
Sander Rossel wrote: I never understood these rewrites that should basically produce the exact same application
It usually comes down to "training issues". If you do a rewrite that maintains the same general look and feel, the user base is more accepting.
We're trying to get permission to do a rewrite, and the only thing that changes for the user is a minimal appearance changes, including better layout practices, fluid design, color changes, and small menu changes). The REAL changes involve the code that makes it happen. We're suffering from bad architectural decisions in the front end, and terrible schema decisions in the database. Our code base is over 10 years old and base on ASP.Net Web Forms, and the last time we updated jquery was 2013.
".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
|
|
|
|
|
That's a hard sale, we're going to spend $$$, but you won't notice a thing.
And your employer should hope you won't make the same mistakes you made over 10 years ago 
I totally understand that development can get very expensive and even come to a grinding halt if your code base is a mess and that it may be cheaper to do a rewrite.
It's a very difficult situation to be in
|
|
|
|
|
The tangible difference is theoretical - significantly less effort in terms of maintenance (which is ironically where most devs spend their time in existing apps).
"Yes, we're going to spend time rewriting it, but if we do it right, nobody will notice a difference in the app itself."
Everybody on the team agrees that it needs to be done (the code base started in 2008/2009), and the code has have more than two dozen contractors work on it since then.
".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
|
|
|
|
|
Now you have two systems to maintain.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
