|
What an excellent point... I need to go get some coffee and ponder this....
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
That said, there are perfectly valid reasons to start over from scratch.
For example, if the legacy code is done in lisp.
Anyway, depending on all those thing I don't know about your project, I would probably refactor the code into logical modules/ layers that can be easier exchanged or expanded to newer technologies, when needed, one by one.
So start with planning the architecture you want, and then how to get there.
|
|
|
|
|
I cannot count the number of times I have linked to that article in the past 10 years. This was pure gold advice !
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
I wish I could have linked to it four years ago, it could have saved us a death march. 
|
|
|
|
|
We need more requirements.
- Will it be accessed remotely?
- Will it be accessed from multiple devices?
If so then some or all should be written as web services. Maybe a client app that uses backend web services, maybe a web application that uses and exposes web services.
- What sort of budget do you have?
SQL Server's good. For some stuff. It's expensive too. Have you thought about MariaDB (open source fork of MySQL) or MongoDB? What about Redis for caching?
- Who will be working on it with you? What skillsets do they have?
If it's just you then you can use all the crazy tech you want. If you need to be able to have a team backing it then don't make the specs such that finding a dev or devs who can actually work within the 50 technologies you use is impossible. C#, Javascript, PHP, SQL - all bread-and-butter technologies that are easy to hire for. Start getting crazy and you'll have to either hire specialists or invest in training up staff.
- If it's a pure client-app then what OS?
Windows Devs are cheap. MacOS devs may not be.
- on what infrastructure will it be installed? PC? Servers? Cloud?
All I'd say here is: don't limit yourself to the PC. At least allow reports to be viewed on a tablet or phone so those on call can be on call in comfort. If you can provide basic functions (like "Stop the robots!") then that's a bonus.
However, the big one for me is "manufacturing system". Will it be taking orders from online systems? Will it, itself, be talking to other systems to get specs, data, machine statuses? The Internet of Things is everywhere, especially in manufacturing. Even touching on this to understand how it may affect the system you're writing will give you a headstart into the next 10 years.
cheers
Chris Maunder
|
|
|
|
|
|
SQL Server doesn't have to be expensive; it depends on the application. I've added data base integration to a number of applications over the last couple of years, and the 'Express' versions of SQL Server work just fine. If you can live within the Express limits, you're good to go.
Software Zen: delete this;
|
|
|
|
|
I am in a similar situation, where I have been asked to replace the back-end system for a company that is over 10 years old.
One consideration - the company you are developing this for will have over 40 years worth of data. Do they need to keep all that data live? Or can some of it be archived?
The company I am doing the re-design for is a regional restaurant chain, and their system tracks all of the sales in all locations, right down to the individual purchases made on a daily basis. So after 10 years there is a lot of legacy data that is no longer used, but still hangs around in their database, taking up a lot of space.
On of the things I am putting into place is a data archiving strategy so that only the data for the last 3-5 years is kept live, but with the older data made available if necessary.
Andreas
|
|
|
|
|
Andreas Mertens wrote: On of the things I am putting into place is a data archiving strategy so that only the data for the last 3-5 years is kept live, but with the older data made available if necessary.
That is definitely a good idea!
I had developed a data intensive statistic package which gathered its data from an enterprise search solution on a per query basis and found that it is also a good thing to separately store aggregates in tables on an hourly, daily, monthly and yearly basis. That makes it very speedy in creating reports.
Cheers!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
"I'm developing a proposal to replace a 40 yo manufacturing system with newer technology"
Many of you have made excellent suggestions and points, but the architects in the group have caused me to make a tactical retreat. Being a long time developer, it's natural for me to want to play with all of the latest software tech. Example: I bought SyncFusion's control set two years ago, and I want to use it  , so I'm looking for an excuse. So, the "oooo, shiney" moment has passed - back to reality.
Here's the deal - back in the late 70's this manufacturing system was designed by people that really didn't write code for a living. We're talking a couple of 100K lines of FORTRAN, no design documentation, and the developers are long gone - retired, senile or dead.
Ten years ago, I was pulled in to try and move it to a PC - they actually had missing source code. But we found most of that in a guy's garage. Anyway, since then, I've been tweaking here and there and slowly unraveling the system, peeling away the layers of the onion. In that time, it's become clear to me we're dealing with a relatively simple system - but one with changes to support different customers, bug fixes, etc. This is a nod to the Joel article. He makes some valid points, but I have 200K lines of FORTRAN that simply need to go...
From a business perspective, the original company has been acquired, and there is an opportunity to update this system with something that will actually integrate into the new business IT environment. As a minimum, it gives me an excuse to play with new tech. I might even screw up and convince them to pay me.
The system invests a lot of code to:
- User Interface: data entry, range checking. A few good controls could handle this easily.
- Database operations: these are flat files. Processing queries the flat files and generates even more flat files. Moving the data into a database would further reduce code complexity an order of magnitude.
- Report generation: I have 1000s of lines of code that generate maybe 8 basic reports. More simplification.
- Machine file generation: this is the magic code that creates files to send to their equipment.
My driving goal is to break up this monolithic application and move it into the 21st century as a properly architected 3-tier architecture. The UI doesn't depend on the flat files, the database is independent of other sections of the code, etc. This gives me the flexibility to easily add new features in an affordable manner and more importantly, QUICKLY. Their business is growing, and the system is holding them back.
To address Chris' comments:
- Access: mainly via desktop PCs. But the future beckons, so I'm already thinking of BE FLEXIBLE in the UI. Multiple devices for sure. A key limitation of the existing system is record locking. You cannot have two people working on the same order.
- Budget: strictly ninja (my own dime) at this point. My goal is to learn new stuff. The end of the rainbow is to win the project for development.
- Databases: anything is better than a flat file. I'm not anal about Sql Server, MySQL - any flavor - would get the job done.
- Help: I would do the initial layout. The hard part is taking a dozen years of playing with the existing system and condensing it to items I could farm out. And if I were to win mgt.'s approval, I would be breaking out the work.
- OS: Windows. It's the corporate standard.
- Infrastructure: if I said cloud their eyes would glaze over. If I had to guess, they would give me a server on their network.
- Limitations: I agree, that's why I asked the experts. Being able to pull up a production report is gold for dog and pony shows. And dog and pony shows sell things.
- Manufacturing system: there is a goal to do just that. But they are stuck. The current system, although clunky, is incredibly efficient at what it does. The problem is that it is very difficult to integrate it into their new corporate process - the one group I work with just went multinational through acquisition. So, they have all of this new mgt to make happy. Being able to support new interfaces would be a key seller.
I'm thinking long term here, and if I position the design correctly, the sky is the limit. What I really want is the support contract.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Ah you are doing this as a consultant, good luck, if you get the build you should be able to get the support contract if you don't screw it up  . It sounds like a fantastic opportunity and should set up a small company for some time. I REALLY hope like hell management don't get steam rolled by a big player. All the luck in the world to you!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Appreciate the thoughts. It might completely flop. It's fascinating the politics of this industry.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
charlieg wrote: It's fascinating the politics of this industry
Fascinating is NOT a word I would have used. I did that sort of work in the 90's, not a way to live a stress free life (I had a growing family at the time) but it was never boring. The support resources back then were rather sparse.
I hated the bus discussion!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
charlieg wrote: I might even screw up and convince them to pay me.
Uh-oh ! I wouldn't touch a line of code without a contract, and regular pay-days.
cheers, Bill
« I had therefore to remove knowledge, in order to make room for belief » Immanuel Kant
|
|
|
|
|
topic: "what technology would you select for the UI?"
The entire discussion has blown up in an elegant and useful way. I'm knocking around ideas at the point. Last night, I deleted the UI completely from the ideas I'm knocking around. I'm so late on the current project (some work related, some personal issues that could not be avoided) they might laugh me out of the building. But they know they have a problem with the current system.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
WinForms is the new MFC (still officially supported by MS; but not getting any care or meaningful updates). IF you're sticking with .net for the UI I'd strongly recommend WPF; since with multiple customers it's unlikely you can make Win8 a requirement. WPF may be EoL as well; but in large part that's because WPF.vNext is called Metro, so porting in the future should be less painful than any other options.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
|
I'd question even thinking of using WPF. Sure it's going to be supported in the future? Heard anything lately?? Nope. Checked the WPF blogs? Silence. Even if it is going to be continued it's doubtful it would be backwards compatible.
ed
~"Watch your thoughts; they become your words. Watch your words they become your actions.
Watch your actions; they become your habits. Watch your habits; they become your character.
Watch your character; it becomes your destiny."
-Frank Outlaw.
|
|
|
|
|
I've read the WPF blogs are quiet, but so are the WinForms areas. Right?
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I don't know about WinForms. Not sure what to count on with MS nowadays!
(Stuck in a dysfunctional matrix from which I must escape... Love that!!)
ed
~"Watch your thoughts; they become your words. Watch your words they become your actions.
Watch your actions; they become your habits. Watch your habits; they become your character.
Watch your character; it becomes your destiny."
-Frank Outlaw.
|
|
|
|
|
I have one suggestion not to use WinForms (it's dead), another that says WPF is dead.
Now you see why I asked the question. This highlights the dilemma facing developers and architects. So, keep the UI away from the system with a 10' pole, as others have suggested, and be flexible.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
The enterprise story just isn't quite there (still) for WinRT in my opinion. Until MS gives us a way to manage/curate a corporate "app store" for WinRT apps I see no reason to use WinRT for internal development over WPF. If you were developing for external audiences WinRT would be a no brainer.
|
|
|
|
|
My personal experience is that a new application must support the current and the projected technological environment and skills. Two years ago I started development on a Line-Of Business application for a small company that has no dedicated IT people.
So I chose to use Windows Forms. It's not fancy as WPF or touch enabled like WinRT but it works now, it is understandable by anyone who can use Office, it runs on their computers (Win XP to Win 8) and there are loads of developers that can support this application in case that this company decides to fire me.
|
|
|
|
|
I agree with the majority of what has been said here. I want to add on to BillWoodruff's suggestion. I would suggest using a wireframe / mockup tool of some kind to design the UI for the system via an iterative process of interviewing the stakeholders and users. I would recommend balsamiq. It's a really neat tool that can generate interactive pdf's where button clicks can jump to other pages and so forth. It gives a really great idea of what the UI will do from a functional perspective.
I would focus on the following portions of information gathering (again, Bill hit on most of these):
* What does your current system do really well today? Nothing is a valid answer, I suppose. But if you get this as your response, step down to 'What aspect of today's system is least painful to use?'
* What functionality is the most used? (Good/bad/painful doesn't come into play here)
* What functionality is highest profile? This sounds like the above, but it's not. It could just be a bit of reporting used only by high level managers. It may not be used a lot, but you want to keep the higher ups happy.
* What are the top 3 things that today's system does not do, but you really want it to be able to do? This could become a very long laundry list of things and a brain storming session with the stakeholders would be a great benefit here. 3 is really an arbitrary number, but it forces everyone to really prioritize the things they want in the new system. You may end up with a longer list than this, but the going through the process to derive these 3 will be meaningful for everyone in the long run.
* How many users does the system need to support? You can answer this by finding out how many today's system supports and then getting an idea of what the company's plans for future expansion are.
* What devices will be used to interact with the system? Is this a desktop only application? Are you tying yourself to Windows or some other OS? Do you want it to be mobile? If you want more than one UI, I would seriously evaluate a web based solution. WPF can probably handle multiple display types, but I haven't used it so I don't know.
* If you are learning as you go and this is an enterprise wide system, I would research, research, research. This is probably a given. The biggest concern here is to back yourself into a design corner. Abstracting technology layers as much as possible will give you breathing room you need. I'd also recommend a testing methodology of some kind (TDD). This bullet makes me a huge hypocrite because I struggle with all of these...but I can speak from experience that this is where I've coded myself into corners.
|
|
|
|
|
Did you ever think you might be thinking too far ahead? How about finding out first what they want the system to do (if it's not a direct port) and then pick the UI and tools based on their requirements. The last system lasted 40 years and I'll bet it lasted that long because they could find at least a minimum of support for the OS and software (and by now it's very cheap to support because they don't change anything.) What ever system you come up with, if it's based on Windows then I guarantee it won't last that long. How many Windows 3.1 applications do you see still being used? You can get very fancy with the UI but in the end it just needs to be functional. It will be the back-end data that lives on way after the front end gets replaced so that design needs to be very solid. After all that's probably what this project is anyway. A new front end and their backlog / wishlist of new functionality because they probably will want the old data ported.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
