Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
nibor285921dKnowing how to handle a cunt is an extremely valuable life skill - in more ways than one
stop528321dWelcome to devrant
Great first rant and good luck with your meeting.
What i usually do is 'listen xyz, if you don't do this - as i have recommended you - i am in no way liable nor responsible for any damages, here, sign this waiver of liability. Please interpret this as a very stern warning!'
VaderNT149321dGreat first rant. It's a typical turn of events: Devs build a car made of cardboard (the PoC), and either a manager or customer immediately says "looking great, let's drive this on the highway right now!" ("put it in production"). It crashes and burns, devs say "told you so", manager/customer doesn't understand why it doesn't "just drive" and is angry.
The takeaway is, the term "proof of concept" means very different things to different people. I recommend not building a big car out of cardboard but a tiny car out of real components instead. IOW reduce the scope radically and implement that with production-ready code from the beginning. Driving on the highway will be slow, but at least the car won't fall apart from the airstream. 😉
RANTSMCPANTS36021dIn that situation I'd focus on testing it the old fashioned way mostly and making sure its ready.
I would also insist on a realistic timeline. Heavy static analysis can be dropped in most cases.
Someone needs to look over the code but you need to be careful with code review as that tends to include a review in general.
Your review needs to be targeted and you need to keep track of tasks that can be deferred such as code aesthetics.
Anything you put back you have to let them know that time has to come out somewhere and sometime sooner than later.
Avoid gaining time by cutting corners just rearrange things then be clear you're not doing it in less time just getting it out sooner.