0

Currently in my job im working with a lot of older php systems which don't follow normalised design patterns and are frankly, a mess.

As an ethical developer and someone who always strives to better what Im working on, but also keep within the budget of my employer and their clients, what are my obligations here?

Most of the systems should be rewritten, but often the budget only allows for bodge jobs to fix minor issues. Apart from writing tests, what can I do to both fit within the budget but also add value and integrity to the code?

closed as too broad by user40980, Robert Harvey, gnat Dec 8 '15 at 5:04

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    This really depends on the code itself, what you are scoped to do, what you have time to do, what you can change within regularity frameworks (changing hipaa or pic code may require an audit)... and beyond that, there are so many different things. Of course, the ethical developer would rewrite it in a language other than php so as to not harm the sanity of future developers. – user40980 Dec 8 '15 at 2:15
  • Hahaha indeed you may be right, however since the entire team uses php (Symfony framework) they might not appreciate that. – Aaron Cole Dec 14 '15 at 3:43
6

First, do no harm.

You are faced with a system that works, at least to some extent. It may have huge problems, it may be unmaintainable, but it works, and it keeps the business running. Without a running business, the code has no meaning, so don't kill the business.

Several practices can kill the business:

  • A big rewrite can take so long that the business can't adapt to changing conditions in the middle, and the business may fold before the rewrite comes out. Just ask Joel how this can turn out
  • A big-bang implementation has huge amounts of risk all in one big implementation. If you've gotten anything wrong, it may be hard or impossible to recover. How will your business be if you cannot fulfill any orders during your busiest time of year?
  • There's business logic in the old code that is there for a reason, even though none of the people who understand why it's there are still with the company. A rewrite may not notice the pieces that need to be maintained.

Be surgical and incremental

The best thing to do in this case is to work in very small pieces. When asked to add something to the existing system, take pains to find the smallest possible change that will do the job while minimizing the impact on other portions of the code. Use these tasks to learn the system and understand which portions of the system are subject to frequent change and which are fairly static.

Let sleeping dogs lie. Some parts of the system are ugly, but since they work and are never changed, they should be at the bottom of your list for improvement. Changing these pieces mean you add risk to the business, but no real benefit.

Plan for parallel processing or rapid backout. When you find an area that changes frequently, is important to the business, and really needs to be improved, how do you do it? Very carefully. At a minimum, you should make it very easy to take your rewrite out of the main processing if there is a problem. It is much safer for the business to make big changes if you can flip back to the time-tested legacy code in minutes than if you risk being stuck in a broken state for hours or days. It is even better if you can run both paths at once and prove that the new code produce the same (or better) results as the existing code.

Looking at all these tips, the more you can break the system into discrete bits the more successful you will be at improving the system.

  • Solid advice, in terms of back out we have a rigid review and multi stage deployment system, so I would hope any issues were caught early. I still find it hard to improve software thats so bad to begin with it seems pointless - you can't polish a turd as they say, I guess you can however put it through a refinery / treatment station and end up with something less offensive in the end. – Aaron Cole Dec 14 '15 at 3:42
2

In my experience all you can do is inform your client on the state of their sites and be ready to help if they ask. They can make the value judgement.

If you really want to help, offer to document the project/site structure that needs the most work with a recommendation. Maybe if they see the specific scope of the situation they'll either commit to a larger project, or at least be aware of the scope.

Also, never over embellish or over estimate your position just to make a point. If the previous work really sucks, it'll speak for itself. Consider that at one point you too probably produced something of questionable longevity that someone else is bitching about now. Who knows, maybe the frameworks and languages you'd recommend today will prove to be a costly PITA for someone else.

  • Oh your absolutely right, we all started somewhere and I cringe when I have to work on my old software sometime. Fair point, and what I usually try to do; its hard when the software is used by clients who don't appreciate its quality (or lack thereof). – Aaron Cole Dec 14 '15 at 3:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.