• McGraw (unregistered)

    If the manager is so paranoid about a build breaking, why not try private branch builds? Have some extra build machines that build developers' private branches when something is checked in. If a developer's private branch is good, he integrates the code to the project branch. If not, no harm is done. Other developers sync the latest project code into their private branch. There's no human bottleneck needed because the developer only integrates the code that has passed. There could even be some automation put in place if developers aren't trusted enough to let a build complete before integrating code. But I think if the trust level is that low, you have bigger problems.

  • nobody (unregistered) in reply to code guy

    Where I once worked, the source control manager/build manager insisted on writing the build scripts himself (job security?). We had a lot of fun inventing new ways of breaking the builds.

    My favorite is this one (import a type library by GUID): #import "libid:2DF8D04C-5BFA-101B-BDE5-00AA0044DE52"

  • nameless (unregistered)

    And they wonder why some "he was just normal quiet guy" people finally snap and go killing spree with the guns, just shooting anyone they can...

    Humiliation, in any way, is not a solution.

    If people would learn to treat others with respect instead, maybe world might be slightly nicer place.

  • (cs)

    A few people seem be quite serious (maybe even surly?) about their work environment, but I guess that's okay. There are places that fit that, the most extreme being yesterday's government wtf... the other extreme being a bunch of kids goofing off all day and working all night. I've worked in both kinds of environments, and the middling sort, and haven't minded the seriousness level, even if I can't always elevate to it.

    But sheesh, lay off the human dignity comments already, just go find someplace you're better suited to, someplace you won't drag the mood down at all the time. Embarassment isn't humiliation unless you and your coworkers make it; if you treat all embarassment as humiliation your coping skills must be horrible.

  • Anonymous Tart (unregistered)

    I cant understand why everyone seems to be desperate to ensure that trunk is some sacrosant place. We dont require any reviews/unit tests to check into trunk, but if you then merged that changeset to a release branch without ensuring there are no regressios, I'll have your bollocks.

    Besides, dont you know how cheap a compile cluster is these days? BSD, distcc, ccache, GigE and you're done.

  • javascript jan (unregistered) in reply to nobody
    nobody:
    Where I once worked, the source control manager/build manager insisted on writing the build scripts himself (job security?).

    Not job security; it's often the case, alas, that the majority of the dev team doesn't "get" build management, and typically the management of build scripts is viewed as an onerous chore (since management doesn't consider it part of a deliverable, there's economic pressure to view it this way).

    (It's also all too often the case that developers produce build scripts that are the build script analogy to the daily WTF.)

    If you're in an environment where all the devs really get the need for a structured build, and have the skills to maintain it, you're pretty lucky.

    nobody:
    We had a lot of fun inventing new ways of breaking the builds.

    My favorite is this one (import a type library by GUID): #import "libid:2DF8D04C-5BFA-101B-BDE5-00AA0044DE52"

    Yes, well, that's what blame/annotate are for.

  • Asd (unregistered)

    I break builds all the time. So does everyone else here. I just fix the problem, go to anthill, and click build. If the build process is a big deal then there is something wrong. We say which build is ready for QA (and the automated tests run on them all).

  • Kuba (unregistered)

    The biggest WTF is that they didn't use Aegis. aegis.sf.net

  • Joutsa (unregistered) in reply to Anonymous Tart

    Wish I had a penny every time I hear that.

    Good luck getting distcc to run our esoteric embedded C compiler, then getting said compiler to run on BSD, getting permission from IT management to run that BSD box in company network and finally getting ClearCase to serve files so fast that the cluster makes any difference. No, changing any of these things is not an option.

  • (cs) in reply to DJ
    DJ:
    So uh... Incredibuild anyone? With Incredibuild, there really are no excuses not to rebuild before checking in.

    Except when we tried to use it with our project and visual studio 2003 it would generate so many debug info (pdb) files that the compiler / linker would randomly fail with internal errors. The only way to sort it? A full rebuild without incredibuild...

    Once we upgraded to visual studio 2005, which has a multi-threaded compile system (not as good as incredibuild's , but workable), our build time quartered and we no longer needed incredibuild anyway.

  • (cs) in reply to cklam
    cklam:
    AnthonyG:

    Such would not be fun, but boring. I believe you are ranting, because you were a victim of the "Build Breaker" hat policy perhaps?

    And I believe that you, Sir, have no idea of the concept of "human dignity" ....

    I think everybody just needs to take a deep breath and count to 10.

    I think such policies can go either way. If it's a thing the team decided to do, then it can be fun, even stress relieving. Certainly it can help with team building, but not as a formal sanction. It has to be something the team wants to do.

    These things tend to become demeaning or pointless when they are instituted as policy. You have to wear the dummy hat because you broke the build becomes demeaning if its instituted from a position of authority.

    As far as being adult, or understanding the concepts of fun and/or human dignity....I think we all have a little to learn about that.

  • (cs) in reply to sammy
    sammy:
    Uh?

    CruiseControl + NUnit isn't going to help this situation any. For all we know, they were using CruiseControl and NUnit.

    The problem is that nobody was allowed to check in code without verifying that it passed unit tests first, which would have been fine if the stupid manager hadn't insisted on sitting there and watching it compile at the developer's desk.

    After all, the whole point of source control is that if someone commits something bad, you can always back out of it. Nobody wants to be the guy who breaks the build, but if your team never ever puts anything broken into source control... well, did you really need source control in the first place?

    From the story, it's obvious that they didn't. They had Nightly Builds. Cruise Control is instant builds. You know within a build cycle of time if the build is broken or not.

    The other WTF is "The build was broken last night, we can't do anything today!" Odd, what about "Manually kick off another build?"

    We had a rooster that got passed along each time the build breaks. It dented too many egos and was taken away. I miss the guy.

  • Lalala (unregistered) in reply to Anon
    Anon:
    CAPTCHA: "ewww" -- how fitting.

    God I hate this crap...

  • (cs)
    It appears that your definition of "fun" is the same as my definition of "puerile humiliation tactics that should have been left in kindergarten, along with the people who indulge in them". Fun, for me, is pleasant for everyone involved. I really worry about people who can only get pleasure via scapegoats
    It is however a very good definition of schadenfreude
    Besides, dont you know how cheap a compile cluster is these days? BSD, distcc, ccache, GigE and you're done.
    Only if you only build on one platform. If you build on half a dozen it becomes completely unworkable.
    I mean, who takes overnight to build these days? Even a full Gentoo rebuild can take under an hour if you throw enough machines at it (distcc)
    Try building several hundred thousand lines of C++ on irix and solaris-sparc and you will find even overnight is often just not enough. We do a clean rebuild once a week and it has to be given the whole weekend to complete. And who wants to buy and setup an irix build farm?
    if your team never ever puts anything broken into source control... well, did you really need source control in the first place?
    Yes, source control is primarily so you can view and retain the history of your code. e.g. something broke between version 1.0 and 1.1, lets see what changed. Revision control is for life, not just the previous week. I do agree with the sentiment though, just that I would say that if the automated builds or test suite never failed...did you really need them?
  • (anonymous) (unregistered)

    I worked at a company once, with 40 other developers, 90% with six-figure salaries, where the three "architects" were so paranoid about breaking the build that they insisted on checking in all changes THEMSELVES. What the rest of us did was email the output of diff to them.

    At one point they had a three month backlog of stuff to check in. Now the problem has been solved: the company's assets just sold for thirteen cents on the investor dollar.

  • dkf (unregistered) in reply to MET
    MET:
    Try building several hundred thousand lines of C++ on irix and solaris-sparc and you will find even overnight is often just not enough. We do a clean rebuild once a week and it has to be given the whole weekend to complete. And who wants to buy and setup an irix build farm?
    The time it takes to build a C++ application is its own WTF. Please do not mix it up with this one.

    (Hint: million line C projects don't take long at all to build, even on antiquated hardware.)

  • PitchingChris (unregistered)

    JimJim is right. People could have retreived the version that worked under the module that caused the break. They could have rolled back the broken version to a working version and continue to test minus the latest changes. With any luck, the developer will fix the problem and they can go back and test his module. But they could have tested everything else while he did so.

  • hung (unregistered) in reply to Rafael Larios
    Rafael Larios:
    zip:
    Rafael Larios:
    I broke a build once.... i forgot to check in some file... fortunatelly we didn't have to wear stupid hats or anything.. we just had to fixit before the next build.

    Thank you for that epic tale.

    I was just pointing my personal experience and why it was so different from this WTF... but if you feel annoyed, well sue me.

    WOW - What a comeback! Rafael! You are definitely the smartest guy in this room!

    captcha: first!

  • Diego (unregistered) in reply to Da' Man
    Da' Man:
    The real WTF is that the guy on the photo (with the funny hat - so he's obviously a Build Breaker) got to sit next to three beautiful women!

    Captcha: cognac - well, I guess that would do as well!

    have you ever seen a BEAUTIFUL woman excel at programming or videogames?

    if yes, shoot her immediately. surely it is an alien, or a replicant or a snatcher

  • hung (unregistered) in reply to Diego
    Diego:
    Da' Man:
    The real WTF is that the guy on the photo (with the funny hat - so he's obviously a Build Breaker) got to sit next to three beautiful women!

    Captcha: cognac - well, I guess that would do as well!

    have you ever seen a BEAUTIFUL woman excel at programming or videogames?

    if yes, shoot her immediately. surely it is an alien, or a replicant or a snatcher

    NO. My experience with one hottie was as follows -- senior member of team brought her in (cause she can be 'trained' on the job). Senior member continually 'trained' her for over 2+ years. No contribution to progress was made, but hey - she was 'learning' ...

  • Matt Doar (unregistered) in reply to cklam

    Different workplaces and individuals call for different approaches. The same joke that works well in a bar may not work so well with your mother-in-law :-) Humor beats irritation, and understanding the causes of a broken build beats humor. So, thanks for the congratulations ... I guess.

  • Alex G. (unregistered)

    I am not sure if anyone posted this yet...

    But if you use Subversion, you can could make a pre-commit hook that builds the commited code, and then reject the commit if it fails to compile.

    Oooooor you could go with that manager-sitting-around idea.

  • Gecces (unregistered) in reply to gwenhwyfaer

    Wow!!! An actual adult. I've been reading about these humiliation games. To me, any environment where they are acceptable practice is worthy of resignation. I do have to add a question of this practice to my list of interview questions!

  • Exick (unregistered)

    As someone who does SCM for a living and is familiar with the level of bureaucracy it entails, allow me to say that if someone tried to implement that policy here, there would be stabbings.

  • Tofino (unregistered) in reply to bobbo

    At a whacky dotcom I worked at in 2000-2001, we had a rubber chicken that would be hung from the ceiling above the desk of any build breaker. That was an awesome office and a great crew. Goes without saying the place went under. Fun + Good Code does not == Profits.

  • Anita Tinkle (unregistered) in reply to snoofle

    Jesus.

    I just run a manual build after I've tested something. I don't even bother with NUnit since my classes are tight, small and have as few connection points as possible. If the manual build completes at 5:00PM before I go home, then the automated one will work just fine when it runs at midnight. Has yet to fail.

    If something breaks because of a 2AM coding session, it gets caught by 10:00AM because some developer seems to always want the absolute latest build ever possible (when you have 100s of Sharepoint web parts... you need to build a lot).

    Because the bugs get introduced in such tight windows between builds, identifying what broke the build doesn't take all day to find and fix.

    Build early, build often, and check in as often as you can.

    When you want to stick to a release, pick a point in time and just use that build. Avoid forking your code at all costs!

  • (cs)

    Anyone who's "humiliated" by a harmless broke-the-build trophy is taking themselves way too seriously, and probably no fun at all to work with.

    That is all.

  • Grumpy Young Man (unregistered)

    Surly bunch today. Yeah, "adults" don't need to have this kind of things, but "adults" are responsible enough to actually try compiling before check-in, run their tests, and get a buddy-build and/or code-review to avoid breaking the build or missing check in.

    A lot of places need this practice because a lot of developers apparently aren't "adults". I'm guessing that includes the complainers.

  • (cs) in reply to Diego
    Diego:

    have you ever seen a BEAUTIFUL woman excel at programming or videogames?

    There's my wife.

    Your misogyny prevents you from attracting women other than Jenny Peg.

  • Catbert (unregistered) in reply to cklam
    cklam:
    And I believe that you, Sir, have no idea of the concept of "human dignity" ....

    Human dignity is only acceptable if it doesn't interfere with company profits.

    Catbert, Evil Director of Human Resources

  • AdT (unregistered) in reply to hung
    hung:
    NO. My experience with one hottie was as follows -- senior member of team brought her in (cause she can be 'trained' on the job). Senior member continually 'trained' her for over 2+ years. No contribution to progress was made, but hey - she was 'learning' ...

    She was probably very good, just not at the desk... (maybe under it)

  • Tofino (unregistered) in reply to ptomblin
    ptomblin:
    The presence of a "Broke the build" trophy or other stupid token is a big "find a new job where you're managed by adults" sign for me.

    It's meant as a fun way of turning a crap situation into something with at least a smidgen of whimsy in it. I'm ever so sorry that your office is some sort of buttoned-down IBM-in-1991 hell, but most folks enjoy having the occasional chat and laugh on the job.

    CAPTCHA: "howdy," you joyless wanker.

  • BillyBob (unregistered) in reply to Tofino

    [quote user="Tofino"][quote user="ptomblin"]The presence of a "Broke the build" trophy or other stupid token is a big "find a new job where you're managed by adults" sign for me. [/quote]

    It's meant as a fun way of turning a crap situation into something with at least a smidgen of whimsy in it. I'm ever so sorry that your office is some sort of buttoned-down IBM-in-1991 hell, but most folks enjoy having the occasional chat and laugh on the job. [quote]

    this... then:

    [quote] CAPTCHA: "howdy," you joyless wanker. [/quote]

    Yeah, because you are obviously a barrel of laughs...

  • Xboxnang (unregistered)

    ROTFL....so true...SO TRUE!!!

    got guys here that initiate a fix and then the code falls on it's arse!

    8-)

  • FIA (unregistered) in reply to Tofino
    Tofino:
    ptomblin:
    The presence of a "Broke the build" trophy or other stupid token is a big "find a new job where you're managed by adults" sign for me.

    It's meant as a fun way of turning a crap situation into something with at least a smidgen of whimsy in it.

    Yes, we get that's what's meant by it, the point is that for some people this kind of thing isn't fun, it's demeaning and embarrassing, just because you find something enjoyable doesn't mean everyone else does.

    Tofino:
    I'm ever so sorry that your office is some sort of buttoned-down IBM-in-1991 hell, but most folks enjoy having the occasional chat and laugh on the job.

    Nah, my office is a fairy fun place to work, where people have a chat and a laugh, but part of that is because nobody is forced to do asinine things that make them feel uncomfortable. Mandatory joy is often incredibly joyless.

    Tofino:
    CAPTCHA: "howdy," you joyless wanker.

    You've got a collection of amusing ties don't you, and a mug that proclaims your hilarity. ;p

    But regarding the WTF, am I missing something here, why couldn't the build system do whatever their source controls equivalent of a tag every time the build suceeds, using the same tag each time, then when you required the latest version that built and passed unit testing you'd just check out the last version that built and unit tested sucesfully, and people checking in non compiling code wouldn't break the build.

    Maybe this is just because I see source control as that, control for my source, not my build, I'd rather check something in every day, working or not, so that I have a record of the changes I've been making, but have mechanisms in place to retrieve a given good version from the source control system when required. Obviously how you do this depends on your situation, but once you start having to be careful to check stuff in only when it works you're loosing a lot of the benefit of revision control surely?

  • (cs) in reply to Andrew
    Andrew:
    The best policy I heard was that code should be checked in before lunch break, and a build starts at 12:00. If it fails, everyone should still be around to make sure that the build can be fixed.
    The most important word in that paragraph is "should". However, in my own experience, a close relation to this policy was used and then the fuckers responsible went "to a meeting" followed closely by lunch because they were higher up the food chain to us lowly robot bugfixers that obviously didn't need to eat. For extra grins they also re-checked out the files they had just buggered up. The ratio of lost lunches (ones that should have been taken at lunchtime) to actual tended to 1:1.
  • steve (unregistered) in reply to dkf

    If you think C++ is bad, try compiling Ada. bonus is it gives me lots of time to, ahem, read sites like this.

  • (cs) in reply to FIA
    FIA:
    part of that is because nobody is forced to do asinine things that make them feel uncomfortable.

    Jesus christ, "uncomfortable?" What a pussy.

  • (cs) in reply to zip
    zip:
    Jesus christ, "uncomfortable?" What a pussy.

    Well, yours is the latest in a very long line of comments that go something like "if you don't enjoy the idea of someone being publicly shown up in front of their peers on a regular basis, you're a sourpuss wimp with no sense of fun". The correlation between the willingness to humiliate people because they made a trivial, easily-correctable mistake and the willingness to call other people names because they find your expressed attitudes insensitive, boorish and overbearing is hardly coincidental, not to mention the usual bullies' defence of "it's just a joke, don't you have a sense of humour?". I guess whether or not we need a rubber chicken, a silly tie or a gaudy shirt, you're the man to make anyone objecting stand on their desk with their hands on their head so that you can feel better about not having the courage to leave the herd.

    Far too many people in the software industry need to read Lord of the Flies - and then spend about a week cringing and promising to reform themselves.

    That's if they don't mistake it for a management training manual, which appears to be all too common a mistake.

  • (cs) in reply to gwenhwyfaer
    gwenhwyfaer:
    zip:
    Jesus christ, "uncomfortable?" What a pussy.

    Well, yours is the latest in a very long line of comments that go something like "if you don't enjoy the idea of someone being publicly shown up in front of their peers on a regular basis, you're a sourpuss wimp with no sense of fun". The correlation between the willingness to humiliate people because they made a trivial, easily-correctable mistake and the willingness to call other people names because they find your expressed attitudes insensitive, boorish and overbearing is hardly coincidental, not to mention the usual bullies' defence of "it's just a joke, don't you have a sense of humour?". I guess whether or not we need a rubber chicken, a silly tie or a gaudy shirt, you're the man to make anyone objecting stand on their desk with their hands on their head so that you can feel better about not having the courage to leave the herd.

    Far too many people in the software industry need to read Lord of the Flies - and then spend about a week cringing and promising to reform themselves.

    That's if they don't mistake it for a management training manual, which appears to be all too common a mistake.

    This a very sane comment and it puts the basic issue much clearer across than my "human dignity" comment posted earlier. I should known better than referring to a concept that appears to have been either too complicated or to "uncool" for a large number of posters in this forum.

    Let me elaborate some:

    Fun is when everybody's laughing without laughing about somebody. Everybody is generally having a good time.

    A joke is when everybody in a peer group of people is laughing (like fun) but they may be laughing about a member of said group without said member being humiliated and ideally being able to laugh about himself/herself in a good mood.

    Bullying is when almost everybody in a peer group is laughing about one (or two) members of said group implying denigration, humilation and/or implying inferiority of said targeted group member(s). (I leave out physical bullying here). But bullying can reach farther than that as "gwenhwyfaer" stated so correctly: it can be instituted by introducing some kind of "humiliation badge" like a build breaker award.

    I believe that any kind of "humiliation badge" is very bad and a sign of unhealthy social environment/society. Why - let us look at some examples:

    1.) Before the Taliban regime in Afghanistan was taken down, they made the few hundred remaining adherents of the Hindu religion in Afghanistan wear badges in public to mark them out.

    2.) The segregation of african americans and white americans (separate schools, seating arrangements in buses) in areas of the southern United States between before the 1970's. Here a person's skin colour was used implicitly.

    3.) Apartheid in South Africa. Here a person's skin colour was used implicitly was in different grades.

    4.) The requirement for members of the jewish religion to wear yellow stars on their arm sleeves and for businesses owned by members of the jewish religion to be marked as owned by such in Germany from the second half of the 1930's up to May 8th, 1945. This resulted in the Shoa.

    Now: One surefire way assaulting one person's "human dignity" is to single out that person for some (alleged) failure with a "badge of humiliation" thus reducing that person to the (alleged) failure symbolized through said "badge of humuliation" disowning of the respect any person is due. Bullying is the very start of that process and (as "gwenhwyfaer" very correctly stated: a "broken build award is nothing but bullying.

    On the concept of "human dignity": You bullies will find this useful. Read the Preamble and Article 1.

  • nojdivad (unregistered) in reply to cklam

    Amen to that:

    jump to "The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn't (Hardcover)" at Amazon http://www.amazon.com/Asshole-Rule-Civilized-Workplace-Surviving/dp/0446526568/ref=pd_nr_b_47/102-3562683-4764130?ie=UTF8&s=books

    A blub: We all know them or know of them--the jerks and bullies at work who demean, criticize, and sap the energy of others, usually their underlings. It could be the notorious bad boss or the jealous coworker, but everyone agrees that they make life miserable for their victims and create a hostile and emotionally stifling environment. Fed up with how these creeps treat others and poison the workplace, Sutton declares war and comes out calling them exactly what they are--"certified assholes." Caricatured in sitcoms such as The Office, these brutes are too often tolerated until irreparable damage is done to individuals and the organization as a whole. Sutton's "no asshole rule" puts a stop to the abuse in no uncertain terms. Similar rules have transformed such companies as JetBlue, the Men's Wearhouse, and Google into shining examples of workplaces where positive self-esteem creates a more productive, motivated, and satisfied workforce. If you have ever been a victim, just reading Sutton's analysis brings calm relief, empowerment, and reassurance that you're not alone. David Siegfried Copyright © American Library Association. All rights reserved

    Quoted according to Fair Use Doctrine.

  • (cs) in reply to nojdivad

    I had time to think some about my post 133090. First pls excuse my lack of proofreading it properly since there are some missing words (ninor stuff, though - definite articles and the like). Happens to me sometimes: I think faster than I can type and tadaa: a mental hiccup. Sorry.

    Some books about bullies and some on how to deal with bullies:

    (Remark: There are books called "Art of War" by several authors. I have only listed the books which do not have purely military applications.)

    Apart from the "Dilbert Principle" all works mentioned are in the public domain. I usually put those freely available texts on my organizer/mobile and read them there.

  • bling pirates stinky (unregistered) in reply to cklam

    ======================================================================================================== APPPPPPPPPPPPP STARTSUP INIT CALLED &#(&#)(*#&#&&###############################################

    "hey, did you commit a really annoying debug"

    btw, previous poster, i like your size

  • bling pirates stinky (unregistered) in reply to nojdivad
    nojdivad:
    Amen to that:

    jump to "The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn't (Hardcover)" at Amazon http://www.amazon.com/Asshole-Rule-Civilized-Workplace-Surviving/dp/0446526568/ref=pd_nr_b_47/102-3562683-4764130?ie=UTF8&s=books

    A blub: We all know them or know of them--the jerks and bullies at work who demean, criticize, and sap the energy of others, usually their underlings. It could be the notorious bad boss or the jealous coworker, but everyone agrees that they make life miserable for their victims and create a hostile and emotionally stifling environment. Fed up with how these creeps treat others and poison the workplace, Sutton declares war and comes out calling them exactly what they are--"certified assholes." Caricatured in sitcoms such as The Office, these brutes are too often tolerated until irreparable damage is done to individuals and the organization as a whole. Sutton's "no asshole rule" puts a stop to the abuse in no uncertain terms. Similar rules have transformed such companies as JetBlue, the Men's Wearhouse, and Google into shining examples of workplaces where positive self-esteem creates a more productive, motivated, and satisfied workforce. If you have ever been a victim, just reading Sutton's analysis brings calm relief, empowerment, and reassurance that you're not alone. David Siegfried Copyright © American Library Association. All rights reserved

    Quoted according to Fair Use Doctrine.

    Quoted according to said button on hypertext markup page

  • dnwiebe (unregistered) in reply to jgoewert

    Two years ago or so, I went to work as an architect for a software firm that was using a text editor for an IDE, a two-line MS-DOS batch file for a build system, and a tree of subdirectories for "version control." (There was a directory of source code for every version of the software "in the wild," and if you made a change somewhere, you had to go through all fifteen or twenty directories and make the same change in all of them.) At least the directories weren't particularly leafy: there were only two Java packages in the entire project, one of them with over 400 source files in it. There wasn't a single abstract class in the entire code base, and the only inheritance was the kind Swing forces you to do: none of the proprietary classes were extended by anything. Nightly builds? Weekly builds? Automated unit testing? Don't make me laugh. The Test was a spreadsheet listing all the steps that had to be gone through manually with a "clean" installation of the software before it was pronounced tested. It was tested, according to that procedure, about once every six to nine months.

    So first of all I got them using Eclipse and CVS, wrote Ant scripts for all of their builds, and established an ironclad unstable-trunk policy to make them bud off branches for releases rather than releasing from the trunk.

    Then I tried to get them interested in automated unit tests, which was a chore because they saw it as spending twice as much time to write the same amount of code...and it was difficult, because their code was extremely monolithic--not tiered at all. There were strings of SQL text right in the Swing user interface, and Swing listener triggers right in the database code. (If they could have found a way to make the stored procedures call Swing, I'm sure they would have.) Code like that is tough to write tests for.

    So I waited until the development manager was out of town for three weeks, and I went into the storage room and pieced together a working computer out of a bunch of non-working ones (Pentium II, 200MHz, 256MB, etc.), installed Linux on it, got CruiseControl running on it, and hooked up a bunch of X-10 hardware. Every time anybody checked anything into CVS, the new build server would wake up, download a clean-room set of source from CVS, build it, and run all the unit tests. If anything failed, an X-10 unit would go CLACK! and a big, bright, red rotating beacon in the middle of the development cube farm would come on (I got it from a DJ supply house) and stay on until the build server succeeded in making the build and running all the tests; then the X-10 unit would go CLACK! again and the disco light would turn off.

    CruiseControl includes a website where any developer can go to see who made the last change and is therefore being held responsible for the broken build. Whenever the disco light would flip on, somebody would get very busy, and would stay busy until the light went off.

    Code quality began to improve immediately, and people started to see the benefit of unit tests, and start to join me in chafing at the restrictions the monolithic architecture placed on automated unit testing.

    However, we still had problems with some developers writing and submitting untested code; so next I downloaded the Emma code-coverage tool and fixed it so that all the Ant build scripts on the build server ran the unit tests under coverage analysis. I put together a package-by-package list of minimum allowed coverages, and had Ant compare Emma's findings to the minimums list, and flip on the disco light if not enough of a particular package was covered by tests.

    Not too long ago, I moved on from that place; but I have wondered how they've been doing without me. Have they kept all that stuff in place and continued to raise the minimum-coverage requirements even when it forces them to tier their code in order to test it? Or did they get rid of all the continuous integration, source-code control, and automated-testing policies I put in place as soon as I left, because the suits thought they were too much trouble?

    I have my suspicions, but as long as I never go back there and actually check, I can have my fantasies as well, which are much preferable.

  • Mike T (unregistered)

    Its all about striking a balance for the type of application you are developing. If developing a flight automatic pilot computer then pedantic build and release procedures are a valid engagement.

    There are 2 main products that fulfil this niche by having pre-commit delayed builds:

    • Zutubi Pulse
    • Jetbrains Teamcity

    A pre-commit build is indeed one way of solving this problem, but for example our compile and test takes so long that the private builds would saturate our build environment.

    For that you need to look at hiring the right people with the right attitude. Getting buy-in from a development team requires explaining and outlining the benefits and then having a team that have the right mentality to implement them.

  • guru (unregistered)

    I liked the solution from akimbi. Integrates with a bunch source control systems, builds, spawns unit tests on virtual machines and ofcourse.. points out whats broken.

  • George Mc (unregistered)

    Jebus, what a farce! I broke the build today. Do I care? Well, yes, but not very much. It's a fact of life. Why did it break? My IDE's CVS plugin (guess which IDE we use) buggered up and missed out a few files from the commit. So, I ran the build locally, it passed and I checked in. Had someone been stood over me, he too would have agreed that, yes, I'd compiled and tested the code, and it was fine to check in. What a pointless bit of ceremony

Leave a comment on “The Source Control Manager”

Log In or post as a guest

Replying to comment #:

« Return to Article