Yesterday I had to be pragmatic. Responsible. Sensible. Not technically but monetarily. I had the chance to go for the technically best solution and opted for quite the opposite.

And I would do it again.

There is a service in our company that produces files for the print production process. One of our website takes the files used for that and parses them to get some informations onto the website.

The format was never really documented so it was trial and error. About 10 years ago.

The importing code still works today. Probably all possible weirdnesses that could occur are respected by now.

Now the service is going to change and this file format will no longer be produced. Instead there is another clean seaming interface to get these informations from.

As an architect I would say that we need to change the importer to get rid of the old legacy importer and get our data from a clean interface.

As a product manager I ordered the new service to be extended and produce the exact same file format. Keeping the legacy code as untouched as possible.

Why?

Simply because it’s not my project and I can not possibly spend any resources on it.

Yes, I know that every line of code saved probably saves money in the long run as well. But it isn’t so much about the money.

It’s about the time.

The other project has a plan and a deadline, some milestones probably. My projects have dates set too. Fitting a change in my schedule would be done by prioritizing it first and it would come out pretty late on the schedule effectively delaying the other project.

Or if someone would decide that the other project is too important to be delayed all my projects would be delayed.

So it’s best to decouple both projects and find a solution on one side only. As a result legacy code would be kept alive and some more weird code would be created. But all projects have a chance to be on time.

architecture · Legacy Code

<< Google Analytics introduces The Social Relationship

ChromeOS, Android, OS X, iOS, .. Quo vadis operating systems? >>