Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "project takeover"
-
Let's get rid of the developer training: Pair Programming
Let's get rid of the software testers: Test First Programming
Let's get rid of the project managers: Agile
Let's get rid of the project planners: Scrum
Let's get rid of the system admins: DevOps
Let's get rid of the security guys: DevOpsSec
Let's get rid of the hardware budget: Bring Your Own Device
Let's get rid of the servers: Cloud Computing
Let's get rid of the other scruffy guys: Outsourcing
Let's get rid of the office space: Home Office
Let's get rid of the whole fucking company: Takeover9 -
oh, it got better!
One year ago I got fed up with my daily chores at work and decided to build a robot that does them, and does them better and with higher accuracy than I could ever do (or either of my teammates). So I did it. And since it was my personal initiative, I wasn't given any spare time to work on it. So that leaves gaps between my BAU tasks and personal time after working hours.
Regardless, I spent countless hours building the thing. It's not very large, ~50k LoC, but for a single person with very little time, it's quite a project to make.
The result is a pure-Java slack-bot and a REST API that's utilized by the bot. The bot knows how to parse natural language, how to reply responses in human-friendly format and how to shout out errors in human-friendly manner. Also supports conversation contexts (e.g. asks for additional details if needed before starting some task), and some other bells and whistles. It's a pretty cool automaton with a human-friendly human-like UI.
A year goes by. Management decides that another team should take this project over. Well okay, they are the client, the code is technically theirs.
The team asks me to do the knowledge transfer. Sounds reasonable. Okay.. I'll do it. It's my baby, you are taking it over - sure, I'll teach you how to have fun with it.
Then they announce they will want to port this codebase to use an excessive, completely rudimentary framework (in this project) and hog of resources - Spring. I was startled... They have a perfectly running lightweight pure-java solution, suitable for lambdas (starts up in 0.3sec), having complete control over all the parts of the machinery. And they want to turn it into a clunky, slow monster, riddled with Reflection, limited by the framework, allowing (and often encouraging) bad coding practices.
When I asked "what problem does this codebase have that Spring is going to solve" they replied me with "none, it's just that we're more used to maintaining Spring projects"
sure... why not... My baby is too pretty and too powerful for you - make it disgusting first thing in the morning! You own it anyway..
Then I am asked to consult them on how is it best to make the port. How to destroy my perfectly isolated handlers and merge them into monstrous @Controller classes with shared contexts and stuff. So you not only want to kill my baby - you want me to advise you on how to do it best.
sure... why not...
I did what I was asked until they ran into classloader conflicts (Spring context has its own classloaders). A few months later the port is not yet complete - the Spring version does not boot up. And they accidentally mention that a demo is coming. They'll be demoing that degenerate abomination to the VP.
The port was far from ready, so they were going to use my original version. And once again they asked me "what do you think we should show in the demo?"
You took my baby. You want to mutilate it. You want me to advise on how to do that best. And now you want me to advise on "which angle would it be best to look at it".
I wasn't invited to the demo, but my colleagues were. After the demo they told me mgmt asked those devs "why are you porting it to Spring?" and they answered with "because Spring will open us lots of possibilities for maintenance and extension of this project"
That hurts.
I can take a lot. But man, that hurts.
I wonder what else have they planned for me...rant slack idiocy project takeover automation hurts bot frameworks poor decision spring mutilation java11 -
I started reading “The Phoenix Project” by Gene Kim. And in the first chapter itself two people from the IT department get fired, and the author is forced to takeover the CIO position. Damn, now I’m shook. Is Tech really that much under appreciated and management that much hostile ?4
-
"I need help"
I joined this new service based company and they dumped this giant messed up jquery/php spaghetti project on me, with no comments or any technical documentation. It's completely unmaintainable.
It's been a couple days, and it has already started to take a toll on my health. I feel anxious, causing me nausea at times. I wanna quit, but no other developer is free to takeover in their company.
Am I a crying little bitch? I wanna man up to it, but it's shaking my peace of mind.
It's pile of garbage, and they want me continue working on it.
I know some of you would say, it's an opportunity to fix something. But they don't want changes or fixes. They want me to continue piling it up with more features, ultimately increasing the technical debt.6 -
Not a horror. I'm rewriting services.
It started as a help request. I was asked to help with completing a service dealing with push notifications which was a research prototype. It was suggested to keep core part of it, but it was so awful that I just removed all files and wrote the service from scratch.
The second service had been developed for more than a year by a junior and then by our manager who wanted to complete it as fast as possible, without taking care of code quality. Then I was asked to take over the project and after some time I agreed with one condition: I'll have 1 month on takeover. But when I looked at the code, it became clear that it's much faster and better to rewrite everything except API and database than to takeover existing code.
The third service dealing with file exchange was working, but the junior who wrote it advised to rewrite it because it was a very simple service. So, I initiated rewriting, designed a new API and reviewed the final result.
And now I'm dealing with the fourth one. It was developed in my team but not under control. Now, when I "inherited" this complicated project, I decided to rewrite it because it should be simple, but it doesn't. It features reflection, layers inside layers, strange namespaces, strange solution structure. And that's after months of refactorings and improvements. So, wish me luck because I want to keep part of the infrastructure, but I don't know if it's possible.