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
-
Since this project of mine has proven to be a great success in the company (it works impressively well!!!), mgmt decided that other teams should build their own slackbots. Sounds reasonable...
I already have a complete working solution that can do plenty of things. Adding a few more new features is a breeze. That would be a good idea as this automation could be a unified solution for all the teams.
I offer mgmt to add those 2-3 features they want to my robot. And I am answered with "We have hired a team, they are being trained now. Once done, they will build the slackbot to do that thing we want".
Sure... Give me the job to make it work in 1 week VS hire a whole team, spend a month training them and ask them to reinvent the wheel.
Why not... -
I'm staying on my own route' I'm making commits to my original version of the automation and staying away from their ported-spring-wannabe code. I wonder how is it going to turn out, since when (if) they manage to launch the Spring version, they can't make me maintain it and I'll keep on developing my own branch. Also, they'll have to somehow backmerge all the changes I've already made, which I know is going to be paiinnfullll.
I'd sit back and enjoy popcorn watching them running blind in a field with rakes lying around if I weren't asked to guide them. -
@Demolishun It does infra, codebase and release-cycle-related tasks. It's a software robot.
-
@Ranchonyx Nah, there is no reason @Root would show up...
-
Track your hours maintaining and improving the project. Add the same features they do. Record benchmarks, and most importantly: all costs involved.
After a few months, show a VP what expenses would have been for your version, how much faster it is, and tell them that the demo they watched wasn’t the ported code, but your original code because their team missed the demo deadline despite you helping as much as possible. And then show their expenses and their version’s benchmarks and reliability.
Speak the VP language: money and lies. Guaranteed, the VP will get very very angry at someone — likely at them. Unless s/he owes them a favor.
In short: Destroy them, and have no mercy. -
@Root yeah, but... what do I gain in this.. :) A pat on a shoulder and a "good job, good boy"? naah, not worth it.
It's a corp client which hired our company. It's not my direct employer. -
@netikras Ahh, nevermind. I must have missed that part.
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
java