- 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
Hmm - what would this be then? Approx CiMM level -1.5 ? Good software engineering caricatured?
Admin
Ugh, I can't believe that; utterly ridiculous. Although make files /are/ quite a bit of trouble... ;)
Admin
well I guess today can be considered overtime if it is a holiday.
How about we call big tech lazy slobs who hire anyone who breathes air and enjoys the company of people who are less intelligent than well an ant. Ah the memories of working with those who have to spend several seconds searching a keyboard for the right letter to finish their emailed thoughts!
Admin
Did you get beer and pizza on Merge Day?
This is the best Merge Day ever!
Admin
w00t...
Happy Merge day everyone
captcha = captcha
Admin
Now just add that they ran the whole compile/deploy process on the oldest/slowest machine known to man so that it took at least a day to complete. And add that the whole compile/deploy process frequently broke and had to be redone over a couple days time before the environment could be unfrozen and returned to normal development, and you'll have my previous company (Except that it wasn't 1st Wednesdays for us)
Admin
<blockquote>
I can almost hear all of you source control experts cringing, thinking that's the exact opposite of how it should be done: everyone should work in the trunk and branches should be created at the time of incremental releases.
</blockquote>
Actually, no. It *is* a good thing for separate projects to work in separate branches. The only WTF is that there is an ordained "Merge Day" to bring everything back together, when in fact one should merge back up to the parent branch *as soon* as the changes made in that branch are tested and working. And one should regularly copy down changes others have made to the parent (as soon as possible, without disrupting the work you are doing), so as to bring in new API changes or other changes that will affect the code you are changing.
It's amazing how most people do branching totally wrong. It's not actually that hard when you think about the problem you need to solve -- changing code without others' changes screwing you up, or your changes screwing other people up.
Admin
I recall a similar effort once: an tech partner was used to enhance the existing staff when the existing staff knew that was a problem due to the tech partner not knowing the business. Yes, the same thing happened the consultants recommended products their company had for sale and management bought them right up.
At any rate the merge day happened to be the day most developers took off for various arcane reasons and left the contractors to deal with the mess they created.
<gotta love it/>
Admin
If Big Tech is who I think they are, then ediabitzocity59line.com got what they deserved. Big Tech has fucked up every piece of software they've touched in the past 50 years. Big Tech has botched every concievable kind of software- operating systems, compilers, spreadsheets, database servers, and every type of industry specific application; you name it, Big Tech has written the "worst of breed" in every last category. Big Tech's most important contribution to software development has been providing case studies for everyone else to read, so we don't repeat their antics.
Big Tech has some nifty hardware patents, though. They're why we can have TB drives.
Admin
If I were Jim, I'd just maintain that tool and free up several hours per day.
Admin
Care to elaborate on your suspicion? I would be interested in reading some of these case studies.
Admin
I work at one of the major players in online travel, maybe or maybe not the one your talking bout. If you're talking about us, you've got it a little bit wrong, and if not, I'm both shocked and not shocked to hear that one of our competitors is in just as sorry of an SCM state as we are.
Our Merge Day is actually a week long festival, including Upgrade Days, during which all of the 100s of cross dependencies between our many components are upgraded to their latest release versions and dependency problems are resolved. Then we have Merge Days during which all of the features and bug fixes are pulled in from their various development branches a few at a time and compile tested, and slowly gotten to compile.
One of the ways in which this is better than the above story is that there is a dedicated team for doing this merging, so the people and teams who actually wrote the code have little to do with the merging, or the upgrade process. The result is that by the time the product goes to the testing environment, it has little to nothing to do with the code that the teams actually wrote, and over the next month or two in testing the code of each project must be gotten back to a functional state from whatever state it got to during the Merge Days.
Admin
Ah...so the sirens at 1pm on the first Wednesday of each month are for Merge Day celebrations.
Admin
YES! There we are! Finally! A punchline! It's about time we have some wtfs with punchlines again!
Admin
Hmm, a manual and fragile process for locking something so that others can't touch, and then a manual and fragile process for unlocking. Just like yesterday's WTF!
Admin
Got me stumped. Even ignoring the "worst of breed" part, I can't think of a company that has done all those things. The closest I come up with is referred to as "Big", has been around 50 years, has only botched half their operating systems, their database is far from "worst of breed" (unless you consider the admin gui as the most important feature of a database :-) and never wrote a spreadsheet application. I guess they bought a company that had one, but it was already on the way out..
.. unless you mean Microsoft, and the 50 years thing was just to mislead us. How many hardware patents do they hold?
Admin
Hold the phone, Anonymous.
I've worked on a non-WTF do-the-work-in-the-branches project. While it can be done well, I think it's riskier than it looks. Fundamentally, there's not much difference between work-in-the-branches and the multiple-checkout approach, except for some apparent cohesiveness with the checked-out modules.
The main problem with this approach happens when a team (or microteam) works on modules which are heavily referenced elsewhere. The work-in-the-branches idea lends an air of isolation to the project. A developer starts thinking "I'll just change the function return type here in the common module, check out the several dozen other files that use that function, edit them to use the new return type, then count on the AutoMerge function to bring everything back into the trunk. It shouldn't upset anyone."
As if.
While that is clearly WTF thinking on the part of that developer, it's too easy to get there with the work-in-the-branches idea. I think it's much better to encourage the idea that when you work on a common module, you are working with the trunk, and that if you have to check out a few dozen files to make your change, you're going to need to coordinate that work with everyone else first. (And find out why it was a WTF idea to begin with when the rest of the team slams you).
Admin
No, if you read carefully, I think the Big Tech in the article is not the Big Tech you were referring to. I obviously do not know since it's not me who contributed this WTF, but the Big Tech you are talking about does not do the kind of stuff referenced in the article. Also, their directors... well, I do not know how many of them are likely to sit on ediabitzocity59line.com's board simply due to the sheer inequality in size.
Admin
It is amazing how"Big Tech" can take a compelety rational product category (Source Control) and make it completely complicated.
A clear case of finding a comple/enterprisey solution for a simple product.
Admin
Are you working with SourceSafe? Modern source control... like subversion for example... you work off a trunk, make modifications on anything you want to. When it works, you update to get any changes that other people have made, make sure your stuff still works, and you commit it.
You don't need to "coordinate" the work. You just do it. SVN takes care of conflicts. As does a build box. You don't have to "check out" 12 files either. It just keeps track of the changeset between your file and the base file. This makes sure you don't step on other developers toes.
We use branches purely as a way of sanely doing gigantic changes. If you are going to have a broken build on your machine for 2 weeks, it is considerably safer to create a branch and check in your changes whenever you want, just to get it off your computer.
Admin
Make that a clear case of finding a complex/enterprisey solution for a simple product
Admin
What?
No XML !!
Admin
I used to work as a contractor for a large name-brand money-related company that followed this process exactly.
Your code starts life on the month branch. The month branch is the month that your code (which basically doesn't exist yet) is going to "go in" to production. When code hits this branch, the train is rolling. Your code WILL go in that month, even if the deadline is unreachable. You WILL reach it.
Then it moved if I recall correctly to the development branch. This merge was a merge day of truly amazing proportions as EVERY SINGLE PROJECT in this international company merges at basically the same time to the same branch. So everything from anywhere on the September branch goes to dev at the same time. Yeeikes.
You now spend I think two weeks on the dev branch. Then the dev branch is unceremoniously dumped to the development integration branch. Another Merge Day.
Then one month later (or two weeks) the code was dumped onto the integration branch, willy-nilly. Another Merge Day. But at least you aren't on the month branch anymore.
One month later, it's on to acceptance. Usually by this point you had about figured out your requirements. Of course making a change in acceptance, even though it's one month out from production requires a blood sacrifice.
Finally, on to production. Don't blow that merge!
Admin
There could be a whole week of ClearCase WTFs...
Admin
Ah, the joys that ensue when a company's management makes significant technology investment and direction decisions without the input of any technology expertise.
Sadly, all too common...
Admin
Another solution would be to use something like git where any checkout can be a repository and can be pushed to and pulled from pretty easily -- goingto do a big project? check out the latest from the trunk, start working and committing in that repo, pulling other people to work with you and push their changes to your copy, when all the work is done, you can pull from and then push to the trunk again, all the while maintaining full version history of all of the involved files. NOTE: The working repository should be on a machine that gets backed up! That is the downfall of not having all versioning done on a central repository server.
Admin
Was the "clear case" reference INTENTIONAL? Clearcase is a program of this kind!!!
Steve
Admin
The work-in-branches approach was not SourceSafe, but one whose Big Feature was branches (and I have little doubt is the same VCS obliquely mentioned throughout this thread). The work required to merge in major changes seemed to catch everyone by surprise on a regular basis (though, thankfully, not planned to catch everyone by surprise on the first Wednesday).
Many tools, even SourceSafe, can be used successfully, IF you take care to do better than a CMM 1.5 maturity level (that's funny, btw) development process. Break up your project into SOA modules, or whatever. The point is that the "do the major work in the branches" approach has, from my experience, mislead too many developers into believing that a gigantic change would be not a big deal to just merge back into the trunk. If you have well-disciplined developers to begin with, you could use SourceSafe if you wanted and still have good results.
Admin
Yes it's deliberate, as he also refers to Rational, which bought ClearCase from Atria before being bought by IBM.
It's not fair to blame ClearCase though. For all its faults it's a pretty useful tool. The WTF is purely in the braindead way of using it.
ClearCase is a little like perl or VB, easy to abuse, but a useful tool in the right hands.
Admin
words...so...big and ... scary!
Oh noes!
Admin
9 days for the junior programmers doomed to fail
7 days for unit testing on their laptops so slow
3 days for rushed QA biting their nail
1 day to halt them all, 1 day to find them.
1 day to bring them all and in the darkness bind them.
Yeah, it comes out to 20 days per month. Apologies to Tolkien.
Admin
Yes, I believe both references (rational and clear case) were meant to be references to particular products from a particularly large corporation, aka "Big Tech". Whether or not the poster is correct on who "Big Tech" is, the products definitely fit the bill. So does the M.O. of the supposed "Big Tech".
Cheers,
Shawn
Admin
I doubt it was IBM. It seems like something EDS might try though.
Admin
I thinkg my references were perfectly RATIONAL
Admin
Shut up you!
I like'em long.
Admin
Yeah, I'd have to agree. If my team is working on Big Feature X and your team is working on Big Feature Y, then we should work in seperate branches so if we break our build, it doesn't hold you up. And if our features are truly independent of each other, then merging should be easy and painless as there should be no conflicts.
captcha: clueless - Why yes, I think they were.
Admin
Ah yes... My last company made a very big deal about getting input from the technology team before spending more than a million on a product that was unanimously voted down... That kind of thinking lead to the loss of their line-of-credit and ultimate doom.
Admin
I'm thinking they share initials with the Men In Black?
-Me
Admin
tl;dr
Admin
A perfect illustration of why corporate politics completely destroys the chances of a company making it good.
I had to read that couple of times, just to make sure it was as big a WTF as I thought it was ...
You may not technically have to coordinate changing oft-referenced modules while using decent source code management (or even SourceSafe :P), but if you're going to change the interface to them or the way they work, you're going to break a lot of code when you check it back in. You really ought to have a little discussion meeting with the other devs (or other project leaders, if your company is too big to do everything with everybody) to (a) make sure your proposed change isn't a WTF, and (b) make sure they know what's going to break and why.
And Happy Merge Day, everyone!
Admin
I've used ClearCase, CMVC, CVS, and PVCS. Given those choices, I'll go with ClearCase.
Admin
by any chance was there anything called plumbers?
Admin
And I'd have to disagree. There's already a mechanism for this, and it's called a tag. Not a branch tag, just a plain old tag.
Branching has the benefits you describe, but you are failing to account for the drawbacks. This WTF perfectly illustrates the massive amount of effort that goes into coordinating branches: namely, merging.
Branches were always intended as forks from a version other than the most recent version. They are meant to be exceptional cases, not a normal flow of development, precisely because merging is so much work. All that time people spend merging is time they could spend developing.
Admin
Feature branches are indeed a good idea, but it's only good for BigFeature parts that require huge modifications and can leave the trunk broken (which is a big no-no). Most modifications are not that big, and don't require the (admitedly low) overhead of creating a branch and the (potentially annoying) process of merging it back in the trunk.
My rule of thumb to know if I should create a branch for a feature/work is based on the sheer size of the modification (if it's to take under pair of days, there's probably no need for a branch), the "incrementalness" of the requirements (can I use several atomic non-breaking steps to implement this? If I can, there may be no need for a branch), the time-span of an increment (not being able to do a commit for half a day scares me, not being able to commit for a day is positively horrifying) and the number of devs working on the feature (if there's a whole team, the work to do more than likely won't check against the previous rules anyway).
As long as you set and enforce the fact that the trunk is holy and can't be broken at any time (and your devs know how to branch & merge of course), development branches will be spawned fairly naturally.
Last, the overhead of branches in "regular" SCM software is making me look at distributed SCM (Darcs, atm). Probably harder to work with on very large team, but each working copy being it's own self contained "branch", and being able to fork from any other working copy/repository (which are usually the same thing when using a DSCM), much more powerful merge abilities (because automatic merging is much more important for a distributed SCM) and the ability to still use versioning when fully offline (since your local working copy is also a repository) may make them worth looking at.
Admin
Merging doesn't take that much time if you do it well. Namely, if you do it often: the content of the trunk should be very regularly merged back into development branches (release branches being an other issue), and by regularly I mean "often" (every week is not "often" fyi, and these guys were doing it every damn month), so that your branch stays in sync with the trunk. This makes the merge of your branch back into the trunk much easier.
Not exactly, there are many kinds of branches, some of which are "release branch" (create a branch, fully stabilize/bugfix it, then release the software from it), "fork branch" (parallel side-project, usually stupid) and "development branch" also called "feature branch". The latter is extremely useful for big modifications (that would leave the trunk broken from time to time because it just wouldn't be possible to do otherwise), or for tests that may not turn out to be good ideas (which would require a lot of work to revert if they were tested on the trunk), or for some big developments that may clash with other people's developments.
An example of fairly recent development branch is Django's "Magic removal" (warning, I didn't precisely follow all of the process so there may be minute errors, but I think that's pretty much how it happened): Django is a Python web framework, people felt that there was too much "magic" going on behind the scene, that made de framework hard to really understand or reason about. Since removing all of the framework's magic was considered a tough, long and very likely trunk-breaking job (great parts of the framework being based on the to-be-removed magic), and maybe an impossible task, a specific branch was created. That way, breaking the builds wouldn't affect the trunk's development, if the magic-removal turned out to be a dead-end the branch could just be discarded without any hassle, and people would still have the ability to work on and use the old "magic" framework until the branch was done, stable and merged back in the trunk.
Admin
What's wrong with using SVN? (Yes, I haven't liked CVS much, but SVN seems quite capable)
Admin
Ah, Clearcase makes a bit of sense. I hadn't realized that Big Tech(tm) had purchased Rational.
Clearcase is a good product, and many projects use it well and without problems. But it has the drawback that it makes it too easy to create a complicated mess if you're not careful. And that complicated mess results in merge days. Ie, lead developers encourage "thick" branches, developers aren't requested to do their own periodic merges after testing, and there are so many branches and labels and arrows in the tree that the developers give up trying to stay on top of things.
Care has to be taken so that the development process does not get tightly tied to the development tools; but this mistake seems to happen with Clearcase quite a lot. I think that if the thought of the effort to migrate to new tools is daunting, then the development process may need fixing. If there is also a full time person (or more) that does nothing but administer Clearcase, then things may need fixing.
Admin
A perfect case study to illustrate why I love Continuous Integration. Aside from the occasional head popping up over the cubical wall yelling "who broke the build?" CI is a joy to work with. Of course, it takes a seriously committed team of superstars and a rigorous testing policy to pull this off, but that's exactly what I had at an old position at a company which was started by the ex-CTO of one of the big online travel companies.
Admin
hahaha, roflmao.
Several years ago I worked at a company where this was part of the software development process. We even had the term "code freeze", which would occur just before a "major release". However it never worked, there were always several guys doing changes after the "freeze". Heh, although I guess it wasnt that bad cause we were merging to the main trunk after completing any feature, so there was not a "merge day" in the sense of having to merge everything. Regardless the process still sucked monkey balls.
over and out.
Admin
That one it doesn't. It takes a dedicated initial-setup time (with the tools that will tell everyone, everywhere, very fast, that the build failed), a machine that builds the trunk everytime it can (of course), it requires that the development teams follow a few simple procedures rigorously (which can be forced via a carrot/stick process), and it requires a fairly good quality, higly automatable/scriptable, low-administration SCM (hint: SourceSafe doesn't fit any of the 3).
One of the only things it doesn't actually resuire is a team of superstars. Commitment is necessary indeed, but not top-notch programmers team. Nice to have, but definitely not required.
Oh yeah, and just to prevent the flames that may happen: continuous integration is not the same as XP, it's one of the process included in the "extreme programming" methodology but while XP requires continuous integration, continuous integration doesn't require XP.