- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
The entire WTF can be summarized as "it's kind of like your daily WTF".
Admin
45 minutes to build? did they use gradle?
Admin
Decent story, but it lacks a proper punchline. "Boss doesn't understand technology; makes unfounded assumptions" is very much 'business as usual' for TDWTF.
Admin
Sounds like they were using gradle… to build C++.
Admin
This sounds very like a heavily-embellished retelling of a submission I put in a few weeks ago.
The heart of the tale was indeed the fact that the project manager had not twigged that: a) if the vacationing colleague had not actually committed his changes to the repository then the build would not pick them up, rendering the manual build futile, and b) if he had committed them to the repository, then the automatic overnight build would have picked them up and included them in the latest build, rendering the manual build redundant.
The message exchange in which I explained to the project manager that it was pointless to do the manual build took only about 5 minutes in total (he's savvy enough, he reacted with an "oh yes of course, well explained"), but the exchange amused me sufficiently (in the wake of a four-year-long sequence of WTFery) that I thought it worth posting up.
Admin
The real WTF is Jackie not pushing her changes (even if they're still in progress) to a branch before leaving on vacation...
Admin
"Boss doesn't understand technology; makes unfounded assumptions" is very much 'business as usual'.
FTFY
Admin
Sometimes you just gotta tell your boss "no".
Admin
[quote user=bvs23bkv33 ]45 minutes to build? did they use gradle?[/quote]
I used to work at a place that had even longer builds. Not only did the build itself take a long time, but there were a whole slew of automated tests that ran as part of the build process, so a full build+test could indeed take upwards of an hour or two. Oh, and check-ins were gated, so your stuff had to successfully build and pass the tests or your changes would get rejected. And the tests were prone to random failures that had nothing to do with the code that had actually changed. Once the higher-ups found out how much consternation this was causing to the devs, they decided it would help speed things up if they bundled multiple pending check-ins together into one gated build, meaning that now your one-line bugfix could get rejected not only because of some random test failure but also because of someone else's broken code. And the bundled check-ins meant that it was never your fault when the build broke, so you just re-submit your changes... and so did everyone else, which naturally caused a vicious cycle that tended to result in simple changes possibly taking a whole day to actually go through.
On the plus side, the frequency of build-breaking changes getting into the main repo went way down.
Admin
I imagine they're just working on the only (production) branch that exists.
Making a branch for each development task is scary. Next, you'll want each developer to maintain local versions of the databases, to isolate changes before they're checked in.
Sigh. Some of the stuff I am trying to get us away from.
Admin
Finally, a daily WTF story that is entertaining! And didn't rely on me having to read code, which I don't ever do. Short attention span, you know.
Admin
Look, a squirrel!
Admin
Not sure if you are being facetious or not.
I know there are several competing ideologies for branching for develepment, integration, and release. Having a separate branch for each development task is one of the top runners though as far as I have seen. The downside is having a billion branches hanging around.
But I am fairly certain that having a local instance of the project database (preferably filled with dummy data) that you can test changes against is definitely a good thing.
Admin
Ok.
Deploy untested changes, from a dev on vacation, code that is in an unknown state, to prod so manager can do a demo in 20 minutes?
Yeah, what can go wrong?
Admin
CEO is not at fault here. One IT resource didn't commit her changes. The other IT resource configured a snail of a build. At worst you can say he should've hired a CTO, but those are usually dumb, too.
Admin
And the cherry on top - GitHub. Why would you use a paid centralized version control system, while there are free alternatives like Subversion?
Admin
You haven't worked with both, have you...
Admin
"Sure! I'll just check in her unfinished changes, which might cause the demo to explode in everyone's faces, which will make those potential clients go home and tell all their contacts that our product sucks and we lose half our future clients.
"You've got to ask yourself one question: 'Do I feel lucky?' Well do ya, punk?"
Admin
You pay for git so you don't have to deal with subversion any more. You answered your own question. Though you could run local git server for free too.
And people saying it's Jackie's fault for not checking in the broken pages in progress... she probably should have made a branch before she left just so they wouldn't get lost if her laptop fell in the ocean.
But that wouldn't help Matt in this case, because then Matt would have made a totally broken build which the boss would have shown off live and would have been worse than showing nothing - and all their other customers would have gotten the broken build too. This is completely the CEO's fault for lack of planning and communication.
Admin
I hope you're trolling. If not, you might want to catch up a bit.....
Admin
"It was the last lo mein he enjoyed because he was fired the next day by the CEO for not meeting his needs and not being sufficiently obsequious and contrite about it. Now he's a homeless hobo and only eats scraps of unwanted moo shu pork from the chinese take out trash bins. Why does no one throw out lo mein, he cried. Why?"
Admin
Another analogy, which you could stretch just far enough. The boss wants you to drive him to somewhere 45 minutes away, and get there in 20 minutes time. You can take the company car, which any employee can access at any time, but the boss wants to listen to the new playlist your colleague was creating before going on leave. Because the playlist wasn't left in the car, and the colleague has the playlist with her, you can't use it without reproducing it yourself.
You can always use a car metaphor.
Admin
If he does indeed understand Star Trek references, why not use "You cannot change the laws of physics, Jim!" ?
Admin
Billions of branches lying around is a sign of a bad work process or undisciplined workers, not a problem with 'one branch per task'. Once the task gets merged into main/master/production/whatever, the branch should be deleted. That way the only branches that exist are work in progress, which is an immediate insight into which tasks may be hanging around too long.
Admin
That would have been a completely different TDWTF if the changes she pushed before going off the grid didn't work....
Admin
If you delete your branches, how do you maintain traceability?
With Subversion, you can at least go back in history and recover your branches, but AFAIK, when a git branch is deleted, it is gone forever.
Admin
Admin
Methodologies in code control vary, and usually depend on what is supported. Branches are popular because in git, they are effectively free (creating a branch just creates a new pointer to the current HEAD). Some, like in Perforce, can take forever (always great fun branching the kernel project, it will stall out for 20 minutes and you better not touch anything because the X server can get unstable), so you generally don't branch and just work on changesets at a time.
Plus, the merging tools vary in quality, which reflects on how you merge branches back into mainline.
Admin
If you ensure a merge commit is always created on merging a branch you still know where they were. Then you just need to checkout that commit and give it a new branch label
Admin
If the major downside to one branch per task methodology is 'I have to remember to delete branches after the task is done', that doesn't sound very scary to me.
And (at least in git) deleting a branch doesn't delete the commits the branch was made from. Those are still there for traceability.
Admin
Can't you just hack into it? Not unless it's plugged in and switched on. Can't you hack into it and switch it on? Not unless it's plugged in. Can't you hack into it and plug it in? Not without a very fast car and a sledgehammer or that fictional teleporter we mentioned earlier.
Admin
It's pretty much business as usual for the majority of companies.
Admin
Two years ago, I would've called this story "BS". But in the last 2 years I worked for a CEO like the one in the story. He actually was pretty tech savvy (as tech savvy as CEOs can get), but he too failed to understand that you cannot deploy a change that takes 45 minutes in 20 minutes "for a demo I am about to do".
Worst case was that he once proposed an idea for a project. Our team lead said "well, this would take us about 3 months, give or take a few weeks". CEO repsonded "great!"
That was the last we heard about it. Until we got presented with a new colleague who was hired for exactly the project that got proposed 2 and half months before. Suddendly there where more and more requirements coming in every day, which pushed our planned release date further back. We tried to reason with him but got a "why, you are working on this for 2 and a half months now, and I got told it would be finished in 3 months. What's taking you so long?"
"Um, actually we only work on this for two weeks now, because we never actually got the go to work on this project...?!"
Yeah, it was a complete disaster, and one of the reasons I left that company.