I am a student that will finish his degree in like 7 months. I have a side job where I am the only programmer for a small company. The web application is for invoices and employee working hours. This application (with legacy code) uses an old framework (cakephp 2.0) and is just too old and has too many redundancy code (like a lot!).

My best geuss is to rewrite everything in django. To finish everything correctly it would take me about 3 months of full time work. My employer wants to increase functionality. For that I also need to change the database.

In about 3 months I will get a fulle time internship at another company. Which gives me a small amount of time to work with.

I am hoping to deliver a small amount of "new" pages at a time during my internship.

So my request/question is: Does anyone have any advice in how I should approach this? And is it possible to work this way at all ?

Keep in mind... I have to make a new database which would have to be populated by the "old" application so both the applications have to work side by side.

  • 4
    And what happens if you miss your time frame (which will most probably happen, since even experienced developers almost never get a "3 months in the future" estimation right)? Then you are stuck, your employer has no working results, and someone else has to clean up the mess? And I guess you haven't ever heard of Joel Spolsky's "Things You Should Never Do"? – Doc Brown May 31 '17 at 4:29
  • No it does not really have to be done in 3 months. It's just my estimation for doing the most important features first. When I am at the internship I would like to keep working at the evening hours. My employer needs to have a working result, that is why I wanted to know if one old and one new webapplication can run side by side. And if people had some advice about approaching this properly. – deltu100 May 31 '17 at 9:40
  • Do you have backup from your employer to invest 3 months of fulltime work just to rebuild the existing application, without delivering any benefit in form of new features? Not that this cannot make sense, but you have to convince your employer, not us. – Doc Brown May 31 '17 at 11:26
  • 1
    Re "students refuse to work with this particular legacy code": Just wait till they get real jobs in the real world!!!:) Learning, practicing, and becoming comfortable and fluent with current tools/languages/etc is indeed vital. But so is working with other peoples' code, which is frequently (and I do mean frequently in the real world) 10+ years old. On a first-things-first basis, I can understand they'd rather not work with old stuff. But if that's what happens to be needed in this case, it's an opportunity to begin developing a needed skill that they're apparently not being taught in school. – John Forkosh Jun 1 '17 at 6:35
  • 1
    Yes I do know this and I agree it is a much needed skill, but my employers company is rather small. We need someone committed to doing the job as i have been doing the last couple of years. Usually student always have the habbit to learn "new" stuff. But like the answers down here suggests, I should battle out between the old code and new code. Try to keep them sepperated in my head. To help the new future employer I will document what I have done to make it easier. – deltu100 Jun 1 '17 at 9:49

Make a toy. Prove, just to yourself, that you can do something in here. Even something that has nothing to do with what they want. If you can do that without breaking everything you're on the road to success. I've told employers that I won't even commit to doing the job until I can see this happen.

Seriously, you're in culture shock mode right now. Everything seems backward and wrong. Welcome to legacy coding. It's the toughest thing in the world to get your head into a code base that is asking you to do things in a way that you know is wrong. Suck it up. You can't snap your fingers and fix it all so settle for incremental improvements as you add new functionality.

What really makes legacy coding so hard is this makes the old and the new go to war in your head. It's like trying to think in two different languages at once. Just keep going back to your sources of the best wisdom of the day. Otherwise looking at bad code all the time will start to make you believe it's OK.

  • Re "looking at bad code all the time will start to make you believe it's OK": Firstly, I don't think that's right, at least not for most people. In fact, more likely the opposite -- reading, tweaking, and sometimes fixing/replacing poorly written code typically improves your understanding and appreciation of what it takes to be good. Secondly, and maybe more importantly, just because it's legacy doesn't mean it's bad. Some legacy stuff was masterfully-designed and beautifully-written, but sometimes in languages/styles no longer in vogue. Recognizing what's what is also an acquired skill. – John Forkosh Jun 1 '17 at 6:21
  • 1
    Yes it doesn't mean that it is bad code. Even though the previous guy had some amazing code smartly done. He also has 12 calculations for weeknumber, which in this case is like 10-12 lines of code. So lets say I get a bug on page1 and I properly fix that bug. If i didn't know that page24 uses the code redundantly, then that means I didn't fix the problem globally. When my employer complains I tell her what problems I am facing with this. She then suggests I rebuild everything in my own way, but I agree with the answers here. So I will keep working with the old one. – deltu100 Jun 1 '17 at 10:00
  • 1
    @JohnForkosh "just because it's legacy does mean it's bad" true. But it very much tends to be. Why? Because we're getting better at this. Computer programming is less than 100 years old. Worse a large code base has the advantage of numbers. Working with it is like trying to understand a serial killers mind. To deep and it affects you. All I'm saying is spend some time looking at other code. – candied_orange Jun 1 '17 at 14:06
  • @deltu100 "keep working with the old" doesn't mean don't change, or even re-factor, anything. I've also had several legacy problems, e.g., opacity of atmospheric water vapor, where the same wrong calculation was redundantly rewritten several places without encapsulation. I encapsulated a fixed version and exhaustively searched the ~75K lines of code for every occurrence. Use your own judgement about what should be changed versus "let sleeping dogs lie", given the totality of tasks you want to accomplish, your timeframe for accomplishing them, and your own assessment of your abilities to do so – John Forkosh Jun 1 '17 at 22:12
  • @CandiedOrange I wouldn't say "we're getting better"; rather, the best of us are getting better. When I started in the late 1960's, virtually everybody was excited and enthusiastic and dedicated about this new and wonderful field. As a byproduct of this attitude and dedication, people developed and applied their skills to the utmost of their capabilities. However, by the mid-1980's, programming had come to be seen as a good money-making career, and many of those who entered the profession lacked dedication, and often even lacked any interest. But the fewer dedicated ones did have better tools. – John Forkosh Jun 1 '17 at 22:30

As already mentioned, leave the old stuff as-is, as much as possible, just tweaking it as necessary.

For the database, if at all possible, just add some new columns to support any new functionality, leaving existing rows/cols as-is so that all existing queries continue to work, either completely transparently with no tweaking at all, or with as little tweaking as possible. If that involves redundancy, etc, don't worry about it at all (unless the hardware really, really can't handle it).

Repeat: don't worry about redundancy. Don't worry about old framework. Etc. Worry about what your client will think at the end of your three months. Your expressed worries seem dominated by the flawed idea that you're "painting yourself into a corner". Guess what???... you're always painting yourself into a corner. The existing code/design may be last decade's corner. Anything you do today, and do your way (your preferred tools, etc), will just be this decade's corner.

Avoiding obsolesence is ultimately impossible. Whether it's the design or implementation that becomes obsolete first is up for grabs. If you have a really deep understanding of the business and its requirements, maybe you can develop a really robust design. Talk about legacy: some banks are still running some mainframe Cobol programs.

Just get the job done so the client can type what he wants to type, and read what he wants to read, and so that it works before you leave, and works correctly. Once you have several (maybe five+) years of real experience, then maybe you can begin letting a corner of your brain worry about the longer-term ramifications of decisions made on the basis of today's requirements and schedules. But for the forseeable future, Repeat: just get the job done. A happy client is the one-and-only sine qua non for a successful developer.


... application (with legacy code) uses an old framework (cakephp 2.0) and is just too old and has too many redundancy code (like a lot!).

Just because you don't "like" something is not a Good Reason to re-write it.

My best guess is to rewrite everything in django.

Does anyone else at this company know django? If not, you're saddling them with something they can't maintain after you leave. Probably wouldn't go down very well.

To finish everything correctly it would take me about 3 months of full time work. My employer wants to increase functionality. For that I also need to change the database.

Do you have a list of requirements that you need to deliver? If you don't have these [broadly] agreed by this point then you have little, if any, chance of succeeding.

So my request/question is: Does anyone have any advice in how I should approach this? And is it possible to work this way at all ?

Does the existing codebase have a complete set of Unit and Integration tests so that you can re-write all or part of the code and guarantee that you haven't broken anything you didn't mean to? If you don't have these, then you probably shouldn't even consider starting this (and it would take you most, if not all, of that three months to create those tests).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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