[lmilcin]

All that is really amateurish way to write unmaintainable code. I specialize in dealing with legacy apps (diagnosing, refactoring, figuring out what to do that would salvage them). Let me share some tips from my experience that will really help you step up your game (real projects I have joined):

1. Don't write it yourself. Your expertise is too precious for the company and you work in a high cost location which automatically makes you too expensive to actually code. Outsource it to some other team in a low cost location. Hire entire team for the purpose of the project, ensure they know most of them will be let go before the project end and ensure they have no vested interest in the success of the project. Provide as little actual guidance on how the problem is to be solved, only very general requirements. Let the team self-organize. Don't supervise (your time too precious, remember?) and only ever involve in discussion about high-level architectural concepts. Expect the application to be delivered to PROD on time regardless of the state and the missing features to be substituted with workarounds.

2. Not happy with quality of the code? Start a rewrite without a good idea on why exactly you are doing the rewrite, what you want to achieve or how you are going to do it. Decide to slowly migrate functionality from the old service to the new one using strangler pattern. Don't get buy in from your stakeholders. Annoy them with requests for more staff while delaying development of critical features and creating more and more incidents. Eventually put the migration on hold having multiple services with unclear boundaries, copies of functionality, nonexistent documentation and new development team because the old got fed up with your bullshit.

3. Accept government contract to move 10 messages from webservice to a mainframe. Ensure you need 5 different features when processing moving the data. Each of the features requires, of course, their own programming language, database technology and their own message format. Use 20M (yes, that's twenty million) LoC. Yes, I have worked on a contract to add new functionality to something like that (10 messages with two dozen fields to move from ASP.NET service to IBM mainframe. 20M lines of code. Polish social insurance administration)

[AwaAwa]

Parent is tactical, and you are strategic. Together you will be employed for life.

[csande17]

> Eventually put the migration on hold having multiple services with unclear boundaries, copies of functionality, nonexistent documentation and new development team because the old got fed up with your bullshit.

Even better: now that you're about halfway through that rewrite, start a NEW rewrite! Continue this process over and over until your codebase is a mishmash of ten different frameworks and development philosophies. That way, you won't be able to combine different components together unless they were written during the same six-month period -- and when that happens, you know it's time for another rewrite.

[Kalium]

I once worked on a codebase that had been subject to this. It had been substantially, but incompletely, refactored at least three times in five to eight years. Everything was a mishmash of half-updated features nobody understood from the dawn of time linked up awkwardly to current methodology.

The product person was more concerned with the font in use than the product, which likely did little to help matters.

[yabai_yatsu]

note to self: stay the fuck away from the Polish social insurance administration domain.

[lmilcin]

I opened a file with C code. I expected you know, the regular stuff, includes, functions, etc. Instead the first line was already a statement, followed by 5k lines of statements.

There was a huge function that had to be split in no less than three separate files and then pulled in with #include directly into function body. These were #included in multiple other places, for greater obfuscation effect.

I opened another file (this time .NET), still same application, though... I jumped with my editor into middle of roughly 25k LoC of code... to be faced with empty screen. A bit surprised, I started dragging the scroll bar and then suddenly the code started showing on the right side of the screen... There was a span of roughly 15k LoC that was indented so much it was off the screen.

[stormdennis]

Scrolling out into the expanse like that showed you have the mind of an explorer. And you were rewarded by discovering code never before seen by civilised man.

[lmilcin]

The IDE that took part in writing that code was too ashamed of it and indented it out of the right side of the screen so it never again has to render these appalling statements.

[lucraft]

I would LOVE to work on this code. Of course not for a boss who wants features yesterday - just to be left alone to refactor it slowly and make it beautiful. Like those people who will unravel tangles of thread into neat balls for free and mail it back if you send it to them.

[DangitBobby]

Any chance this was machine generated?

[ThePadawan]

Well, whatever the case, it was generated by tools.

[lmilcin]

No, it was not machine generated, at least not in conventional sense.

This was written by team of drone developers from specification written by a team of drone analysts.

[oaw-bct-ar-bamf]

4. Split up the codebase into modules. You yourself cannot change these modules. Only the ‚module experts‘ are allowed to change their own modules. Your final executable will consist of ~200 such modules.

If you find bugs / problems you will need to convince the module owners that is in fact a bug in their module.

And modules are delivered only every 4/5 months..

[lmilcin]

Yep. Worked on application like that, too, albeit with only something like 140 modules maintained by team of 20.

It had a repository in subversion but modules were versioned by their owners by making copy of the code in a new folder with version in the name.

Builds were not automated and instead each module owner built it manually in Eclipse and "uploaded" them binaries to svn. Each module had a single owner, nobody else knew anything about the module except for the owner. Builds could not be executed when the owner was not available.

I was required to "prove myself" before I was given read access to module I was supposed to start my work on.

The application had a lot of problems in the form of "there was a bug a month ago and now it reappeared because somebody forgot to include the module in the updated version this deployment".

There was ostensibly a "database layer" but different versions of it were used throughout the application. The versions were really branches of it because they included workarounds for app-specific problems that they did not want to be present on other services for the reason of "stability". This of course made it a nightmare for me when I decided to create a proper Gradle build.

Each jar or class was updated separately. I spent a quarter trying to convince teams with their managers that just versioning everything together and deploying everything everywhere at the same time is going to be a better strategy. They said if updating single jars and classes causes so many problems then updating everything has no chance of working. 2 years after I made the change there was still not a single deployment that would fail.

[pestaa]

How do you begin a complete rewrite without stakeholder approval?

Please advise.

[gchamonlive]

Adopt long cycles, spend most of it rewriting, cram every feature into the last couple of weeks so you have something to show for in the PI Planning. Blame subpar performance on lack of staff. You will luckily be awarded with more workforce you can employ in rewriting code. Repeat until done or fired.

[lmilcin]

It depends on the organization. Most teams in most organizations have enough freedom (and rightly so) to do some kind of cleanup work, improvements, refactorings. When the development team is unsatisfied with the state of the application and they feel they will not get buy in for rewrite (and usually rightly so...) they might decide they will rebrand it as internal improvements/cleanup/refactoring. Have seen it many times.

[pestaa]

Ew, that's a deadly dose of office politics waiting to blow up.

Guess I haven't read the guide on how to make a toxic & dysfunctional workplace.

[lmilcin]

To seriously think about creating unmaintainable masterpiece you must ensure correct environment that will meet the challenge.

[user5994461]

Developers are autonomous, they can decide what to work on and start a rewrite without approval. Call it a cleanup/refactoring if management doesn't like rewrites.