• (disco)

    Shadow Hanzo!

  • (disco)

    If productivity went up but the manager still call them "all overpaid, lazy, and a drag on the company", they should...

    I don't even know...

  • (disco) in reply to Anonymous

    That's pretty standard management attitude. Doesn't surprise me at all.

  • (disco) in reply to Anonymous

    No, productivity went up... but just imagine how it would sore if they didn't waste company time on something else than coding? Jeez, stupid developers having standards? Requireringpowerful computers? Coding is just typing text. My niece can do that. Why do they even pay the devs? I hope they at least stay in late 80 hours a week so they can do all the work they are missing.

    Filed Under: /PHB

  • (disco) in reply to Anonymous
    Anonymous:
    If productivity went up but the manager still call them "all overpaid, lazy, and a drag on the company", they should...

    Productivity is measured by how many hours you're sitting in the cube, slaving away. Of course.

  • (disco)

    This is stupid. Anybody who goes through an interview and then accepts such a position deserves what they get.

    I struggle to accept that any of this story is true.

  • (disco)

    True or not, and whether the submitter made his own bed and shouldn't have been surprised to lie in it...

    Well done @mott555!

    :wtf:-worthy, literary and coherent!

    I enjoyed this bit....

    “Are you aware...”

    One of the many “top priorities” for their company...

    “Are you aware...”

    Some offices invest in cheap white-noise generators...

    “Are you aware...”

    In fact, the office had other infrastructure problems.

    “Are you aware...”

    Developers huddled .... Imagine the quality software written by a team-

    “Are you aware...”

    -wearing gloves, in the freezing cold, while listening to the steady mumble of marketing copy.

  • (disco) in reply to Jerome_Viveiros
    Jerome_Viveiros:
    This is stupid. Anybody who goes through an interview and then accepts such a position deserves what they get.

    I struggle to accept that any of this story is true.

    Have to agree here, taking a position when you know things are like that is a sure recipe for disaster. It's not like they're going to see they've been doing things wrong and make you grand poobah of the company for opening their eyes.

  • (disco) in reply to DocMonster
    DocMonster:
    Have to agree here, taking a position when you know things are like that is a sure recipe for disaster. It's not like they're going to see they've been doing things wrong and make you grand poobah of the company for opening their eyes.

    From TFA: In Stan’s company, they sort of did the opposite. Random directors would storm into Stan’s cube, not to try the software, but to dictate a new mandate without any thought to whether or not it made sense.

    In fairness, you wouldn't know that was going to happen from the interview. I had the good fortune once to work for a company where a particular random director tried doing this to me. My boss, the technical director, put him straight so enthusiastically that in future, if the guy saw me coming, he would promptly dive down a side corridor or into a random room to avoid me. We made a lot of progress very quickly on that project without interference.

  • (disco)

    Interesting. My company' score would be 4 out of 12. How bad is that ?

  • (disco) in reply to Excelsior
    Excelsior:
    Interesting. My company' score would be 4 out of 12. How bad is that ?
    Could be better; we score six.
  • (disco)

    The "low temperature" thing would probably earn them quite a huge fine in Germany. For "sitting tasks with light physical workload" you have to ensure a minimum temperature of 20 °C and a maximum of 26 °C.

    If it's beyond those values, you have to enact increasingly severe workarounds - like, offering remote work, reducing workloads and so on. If your boss doesn't act to at least lessen the impact of non-standard temperatures, you're allowed to leave work.

  • (disco) in reply to RaceProUK
    RaceProUK:
    Could be better; we score six.

    I'm getting a 9.5 for my workplace...

    1. Y
    2. Y
    3. Y
    4. Y
    5. Usually - .5
    6. Mostly... - .5
    7. Nope
    8. Y
    9. N/A (BYOD, because it's a small business) - .5
    10. Y
    11. Y
    12. In a sense, so Y
  • (disco) in reply to Excelsior

    My company scores 11 out of 12, thanks to four separate bug databases (not counting email exchanges, which have the essential details needed to track down the source of problems but aren't included in any of the bug trackers).

    Recently we've got like 30 reports for the same bug. I wish I was better at sed/awk - the answers weren't exactly copy-pastable...

  • (disco) in reply to Gaska

    We got 6, but considering development is a 2 man department in an org with over 1100 employees, I'm pleasantly surprised by 6. We fail miserably on having a quiet environment though. We're beside the main meeting board room and beside our site managers office, his PA, 2 other admin assistants and 15 foot down a corridor with an interconnecting kitchenette we have another admin lady and 2 middle managers. The kitchenette serves the board room and another office with 9 further employees about 15 foot from the door that opens at my back.

    So yeah. Not quiet. We have had to smother posters over the windows in our door and lock it permanently to stop people using it as a general entrance/exit.

    But hey, we have source control! Come to think of it, we'd be on 3 if I didn't force the use of bug tracking/project management web apps.

  • (disco) in reply to Excelsior
    Excelsior:
    Interesting. My company' score would be 4 out of 12. How bad is that ?

    Could be much better, both my internship and my current employer handily beat that. Internship:

    1. Y
    2. Y
    3. Y -- but in several different places in the branch (stream) tree
    4. Y
    5. Y, but in a weird way -- our development process there was robust enough to allow us to fix bugs and work on new features at the same time while keeping the two from getting in each other's hair
    6. 0.5 -- we had some notion of scheduling there, but it wasn't completely communicated
    7. Y -- plenty of specs to go around in that place
    8. Y -- every full-time dev had an office with a door
    9. Y, for the most part -- even the hand-me-down boxes were in reasonable shape, and by the time I left that place, the IT department was resorting to building PCs to spec
    10. Y
    11. N -- oddly enough, that's one of the few things they didn't do
    12. N -- usability issues were raised by QA instead A 9.5 out of 12 -- which isn't bad at all IMO, and easily could be bumped to a 11.5 out of 12 -- which is in line with them being a dedicated software shop, founded by former CS profs who taught back when that degree still meant something

    My current (overall) project team:

    1. Y (although we're in a transition phase between two VCSes)
    2. 0.5 (two step builds + a packaging phase, but we're working to untangle/fix that)
    3. Y
    4. Y, although we have a different problem -- we have multiple bug databases
    5. We have a worse problem -- most of our bug farms are deep-seated architectural mis-steps that are extremely costly to fix, so I'll give it a 0.5 because one-liner bugfixes are rare here
    6. Y
    7. Y -- we have good requirements docs, although some of the devs don't really use 'em the way they ought to, and some of the subtools aren't completely spec'ed because we're building them based very directly on customer feedback
    8. 0.5 -- cube farm, but it isn't all that bad noise-wise
    9. Y -- we're well-outfitted hardware-wise
    10. Y -- we have a dedicated test team overall (although some of the subprojects could use dedicated testers as well)
    11. Y -- we actually give developer candidates a formal programming aptitude test. Beat that, Joel!
    12. 0.5 -- we are the hallway usability testers, given how little domain knowledge we have relative to our business analysts and test team. Furthermore, this project is safety-sensitive enough that mere hallway testing is no longer sufficient: we need formal human factors analysis.

    A 10/12 -- quite impressive for a megacorp, but fitting for a project as critical as ours is.

  • (disco)

    I make my company a 6, including two half points; we have source control but a good chunk of the important code isn't in it, and the bug database is so unusable that very few people ever look in it

  • (disco) in reply to Jaloopa

    If we're counting half-points, I can bump my company's score to a not-too-shabby 7.5

  • (disco) in reply to sloosecannon

    We're approximately a 10½ in our group. Practices vary wildly across the university; we employ someone whose job it is (in part) to get better practices instituted through Software Carpentry workshops.

    1. Yes. (Git. Oh well…)
    2. Yes, for at least some of our products. (We use CI, which helps hugely.)
    3. Yes, except it's tied to commits. No change? No build (and no need to).
    4. Yes, JIRA.
    5. Yes, mostly. Depends on the bug.
    6. Imperfect. We have schedules, but are notoriously bad at sticking to them.
    7. Yes, for most of our products. There's one which doesn't and that means that the lead developer gets a lot of conflicting demands and insane schedules thrust upon him. We need to twist his arm into setting stronger non-goals; that'll help him resist the sillier boss-isms.
    8. Yes, pretty good. We sometimes have slight issues with people having telecons, but it's usually no big deal.
    9. I don't know, but mine is pretty awesome, and it's not the best in the room. :smile:
    10. We used to, but he moved to another group this month. He was astoundingly annoying in how he'd break things. He'll be missed. :frowning:
    11. No, but we hardly ever hire anyone off the street. Instead, we poach people from elsewhere who already have a track record of doing good code. I'll count this as a yes in disguise.
    12. Yes, and we do formal usability studies as well. (We've got access to students who do this sort of thing for their degree dissertation.)
  • (disco) in reply to Anonymous
    Anonymous:
    If productivity went up but the manager still call them "all overpaid, lazy, and a drag on the company", they should...

    Quit as soon as possible. Which is exactly what they did.

  • (disco) in reply to Kuro
    Kuro:
    No, productivity went up... but just imagine how it would ***sore*** if they didn't waste company time on something else than coding?

    Unintentional funny-'cause-it's-true?

  • (disco)

    Pretty impressive that companies like this still exist in 2015.

  • (disco)

    We have a quiet office.

  • (disco) in reply to Excelsior

    we're 7 or 8 (depending on who the PM is for that project) unless you count half points in which case we're 8 or 9

  • (disco) in reply to dkf
    dkf:
    10. We used to, but he moved to another group this month. He was astoundingly annoying in how he'd break things. He'll be missed. :frowning:
    I used to work with a tester who was like this, way back in the mid 90s. The products were industrial process monitoring and control equipment, and some of the larger ones could do SCADA-style supervisory functions with complex interactions. They, as most such things did at the time, used a "database" of functional blocks linked together to produce the required effects. Among these blocks were the expected things like PID loop controllers, lead/lag, and so on, but also logical operators like AND, OR, and NOT. And this brings us to what he did to break the software.

    (Marginally relevant point: he was related to the main guys who ran the Richardson's gang - the main rivals of the Krays - in the 1960s.)

    So on one occasion he submitted a bug report that if he created a "database" that consisted of 501 NOT blocks connected in a loop, bad things happened when you loaded the database onto a machine and tried to run it.

  • (disco)

    I once scored -80 on a test that had a minimum of 0. But that was by cheating* to try to get a higher score than maximum, and I got such a high score that it overflowed.

    Also 0 was a perfect score, so negative would actually be superhuman, not superhumanly bad.

    *It wasn't a test test, it was an online amusing thing. Though it does collect maximum and minimum scores and display them to all other users.

  • (disco) in reply to CarrieVS

    The colour vision thing, right?

  • (disco) in reply to aliceif

    Yeah, that.

  • (disco) in reply to ijij
    ijij:
    We have a quiet office.

    Oh. We just had a meeting about re-starting use of SVN.

    Developer: "I'd like to have separate repositories for test and production"

    So.

    That changes our score by somewhere between -1 and +.5, I'd say.

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    So on one occasion he submitted a bug report that if he created a "database" that consisted of 501 NOT blocks connected in a loop, bad things happened when you loaded the database onto a machine and tried to run it.

    So, ye olde ring oscillator, I see -- I'm surprised the software didn't just sit there in its event loop, faithfully toggling bits...

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    501 NOT blocks
    Because 502 would have obviated the need for notting things? ;)
  • (disco) in reply to ijij
    ijij:
    Developer: "I'd like to have separate repositories for test and production"

    Does he want to lock files?

  • (disco) in reply to boomzilla

    No, probably not, nailing something down by a concept like "locking" wouldn't make any sense to her...

    ...she wants proceed with the upgrade in Production since we can't fix it in Test.

  • (disco) in reply to ijij
    ijij:
    ...she wants proceed with the upgrade in Production since we can't fix it in Test.

    I can't see any problem with that.

  • (disco) in reply to Excelsior
    Excelsior:
    Interesting. My company' score would be 4 out of 12. How bad is that ?

    Depends on how you got to 4. If you are only scoring for actual 'yes' then it isn't that bad, but if you are doing partial scoring to get there then yeah. Of course my view may be skewed by the 4.75 I get by mostly partial points.

    1. Y 1
    2. Most things can .75
    3. Nope
    4. Rarely used .25
    5. Mostly .75
    6. Not one that reflects reality or that devs have access to
    7. Y 1
    8. Mostly .5
    9. Kinda .5
    10. No (test environment, but not testers)
    11. Nope
    12. You are joking
  • (disco) in reply to boomzilla
    boomzilla:
    I can't see any problem with that.

    True. Fixing "it" in Test doesn't fix Production... so sure, upgrade.

    Filed under: I think we're on a very high level of deliberate misunderstanding, here.

    To be un-mis-clear: upgrade the library-stuff in Production, since that upgrade broke Test and we can't seem to fix it and are wishfully thinking maybe it's a config problem.

  • (disco)

    [obligatory comment about now Not All PHP Shops behave this way]

    Small outfit here, so things vary a bit, but including half-points we're around 9/12. I'd rather have priorities than scheduling for my part so that's what I generally get. And I'm BYOD right now, but that's fine because my main rig is significantly fancier than what a peer of mine got given to him by work.

  • (disco)

    Hmm ... we get between 6 and 8 ... but at least two of the fails are directly within my area of responsibility. Damn, I have some work to do. Might make it up to 9 or 10 by the end of the year, that would be something to aim for.

  • (disco)

    ... welp. 1: Yes 2: No 3: No 4: No - but we do want to set a bug/issue tracker up, preferably soon. Gets delayed and complicated by the not-programmers because they don't want to learn how it all works. Also, the boss seems to have some NIH tendencies - he loves the old VB6 mess of awfulness that has some kind of shitty ticketing system kind of in it (which is being used by the other half of the company) that someone here wrote like 10 years before I started working there. 5: Not really? 6: Nope. 7: No. 8: Yes. Not fully silent, but pretty quiet ever since we moved to the other end of the building. 9: They're adequate (VS2010, PCs are good enough), but not the best there are. 10: AHAHA NO. 11: Yes. 12: No.

  • (disco) in reply to Rhywden
    Rhywden:
    If your boss doesn't act to at least lessen the impact of non-standard temperatures, you're allowed to leave work.

    Well obviously you're allowed to leave work, the question is whether you still get paid.

  • (disco) in reply to blakeyrat

    Wait, you don't get locked in your office at the start of each day?

  • (disco) in reply to FullPointerException

    Well I'm not German. Maybe Germans like a little light bondage while they work.

  • (disco) in reply to dkf
    dkf:
    10½

    Sounds a lot like my company. When I first started I was quite impressed at the interest my immediate seniors took in maximising code quality.

    A good thing too, the string of cowboys I worked for previously had the potential to break my spirit. I worked for a company I'll call Big Insurance. The fact that they had a system at all impressed me back in 2008. There were evident holes, of course, such as:

    • The source control component of the development process was apparently complicated. Ideally (and perhaps not physically possibly) the ticket would have had a button that created the branch. As it was, you had to branch from the live environment on the command line or using Tortoise SVN. I was fine with this, but many people made mistakes, and even I branched from UAT once or twice, and didn't have permissions to delete the branch. At least it was source-controlled, but as a lowly grunt I still had to clean up the Real Mess senior devs left behind. In one case (probably ranted about this before) someone had silently overwritten my changes. It took me two days to undo the damage and redo the changes I had made, which probably took a day the first time around.
    • Lotus notes. Like I said, I was just glad the tickets were being written somewhere other than excel spreadsheets or word documents to be emailed back and forth. In any case, Lotus Notes allowed people to change a ticket you were editing, and made you cancel your changes and start again. Still better than the coming-to-your-desk method of issue management. These days I look for jobs with enough seniority that when I say "create a ticket", they listen.
    • People just ignored the system. In one case I was on the other end of a demand for scope creep. I said "5 day SLA extension", they CC'd half the IT management and said "Do your job", as if I wasn't (standard management dick-move). Add to that the guy who decided not to bother naming a branch after the ticket number (again, I've probably ranted about this before) so I couldn't find it.

    I get the impression I'm only going to be able to improve the code quality in future jobs if I keep developing my clout to get away with back-chat when people think "Do your job" is a reasonable phrase to use in response to "follow the fucking rules".

    You'll know things are improving when my old stories are still more interesting than my new ones (for a relative value of 'interesting').

  • (disco)
    1. Yes, mostly. A few people in our $thirdWorldCountry office still email files back and forth, and are encouraged to do so by their managers. :rage:
    2. For testing, yes. Building a gate implementation of hardware is a complex task, and will probably never be a one-step process.
    3. No.
    4. Yes.
    5. No.
    6. Schedule, yes. Schedule that reflects the reality of when things will get done, :rofl:
    7. We have over 40000 specs. We probably have a spec for how many squares of toilet paper you're allowed to use when you take a dump.
    8. Meh. Not bad. We used to be on another floor, where we were between a couple of PMs, who were always in phone meetings about schedules, and an engineer whom I would suspect of being Blakeyrat, if he weren't entirely the wrong type of engineer.
    9. Yes and no. PCs are generally ok to good, but you may have to push to get good. Tools like Office tend to be a version or two behind. Real engineering work is done on racks of fast, water-cooled servers. There are three reputable vendors of the kind of engineering software we use; we use the cheapest of the three, but that's still bloody damned expensive ($25000/year/license), so it bloody well better do the job, and it does.
    10. That's what I do. "Patching" a chip bug would require ~$1e6 to tool up for manufacturing a new version of the chip, not to mention recalling the ones that are already in the field. A hardware company can't survive without testing.
    11. Yes.
    12. Not applicable to what I do. We do have people that do customer-facing software. I don't know how they do usability testing; there have been complaints, and improving it has been a major corporate focus.

    9-ish. Not too bad.

  • (disco)
    1. Yes, sort of. CA's Harvest which sucks, but at least we have separate environments for development, testing and production.
    2. No.
    3. Lol
    4. We have change requests and requirements, does that count? It's not a bug tracker but it's a process set in place for bug administration.
    5. No.
    6. Yes.
    7. Too many specs I'd say.
    8. Eh, I'd say yes, sorta.
    9. Pfffhahaha no.
    10. Yes.
    11. Nope.
    12. Not really a point to that, it's an internal app for a very specific subset of users.
  • (disco)
    1. [Source control] Yes, Subversion.
    2. [One-step-build] Almost, but not quite; see below. I'll say a 0.90 for this. :-)
    3. [Daily builds] Yes; we have, I dunno, maybe a dozen dedicated CI boxes. (That's a guess, because some of the boxes have multiple VMs and I don't know what buildbots are VMs and which are bare metal and what VMs are where.) Each machine does several parallel things.
    4. [Bug database] Yes, with a caveat that we have two DBs in use and which one is used depends on the team.
    5. [Bug fixes first] To some extent, but not all the way. I won't take a point for this question.
    6. [Schedule] Yes, with the caveat that the estimates bear about as much resemblance to reality as politicans' speeches.
    7. [Spec] Sorta? Maybe take 0.5 for this.
    8. [Quiet] Varies; it's never awful, and I have a private office, but most people share offices and even most private offices in the main company location (not where I am) aren't particularly private. Let's say... 0.5 here too.
    9. [Tools] Yes; see below. Edit: though now that I think about it, we're behind on compilers and not using C++11. So I'll take off 0.25.
    10. [Testers] Yes
    11. [Coding interview] Yes
    12. [Hallway usability] I don't know what the people working on the main product do, and this is somewhat inapplicable to the things I work on. I'll take 0.5 here.

    So that's 9.49.15 of 12, or looked at it another way, 8.98.65 of 11 if you exclude #12.

    Elaboration on #2. Perhaps someone has written a script to do this in one step, but there's no offical one-step thing you can get a full build starting from nothing; you need to do a very partial checkout of the repository first, then build. Once you have a few directories checked out, everything else (including checking out everything else you need, including new directories that people have added since you started) happens automatically. AFAIK, most testing is also a separate step (though some testing is done in part of a default build and more can be done with a check target).

    As for tools, well... [image] (That's a dual-socket, hexacore, 2-way SMT box with 128 GB of RAM.) :smile: Not my personal workstation, sadly, it's used by myself and a couple others, though I've been doing more work on my local box lately.

  • (disco)
    1. Yep, that works well.
    2. Not on any project I've worked on. Stupid DB migration scripts.
    3. Half a point here - sometimes it takes 2-3 days to get the repo back to a build-ready state, but we try to push to testing ASAP.
    4. Yep, even if we don't use many of the features, it works fine.
    5. We do try to, yes.
    6. Hmm... Half a point. We schedule what we can, but we often get change requests from the clients in the middle of development, so it tends to get messy.
    7. Half a point again, for reasons above.
    8. Nope, friggin' open spaces.
    9. We've mostly phased out the old 512MB laptops, so yes, unless you're an intern with really horrible luck.
    10. Yes.
    11. Not sure - I didn't, but since I was interviewing for an unpaid internship, they could've figured out they'll test my coding skills later. Half a point on the basis of uncertainity.
    12. Nope - after four months working on the project, even I'm not 100% sure how to use it.

    So it's a seven, plus or minus a few. I'm gonna say "not too bad".

  • (disco)

    Since we seem to be rating our organizations on the Joel Test, here's my rundown:

    1. Yes - That's just an automatic.
    2. 0.25 - Since I write code for a bunch of different organizations that runs on their servers, and the list changes regularly, I can't really have an automated prod deployment step.
    3. No - this is mostly stuff that has no "build" step really, and a lot of it is fixing legacy code without test suites available.
    4. Yes, of course.
    5. Yes.
    6. Yes, absolutely a must.
    7. Also a must, although in my world it's a "statement of work" instead.
    8. Yes, since I'm a 1-person shop. That means it's as quiet as I want it to be.
    9. 0.75 - They're tools I prefer to use, and they certainly work well enough, but they aren't top-of-the-line because those simply aren't needed for what I'm doing.
    10. No - 1-person shop means I am doing everything, including testing.
    11. N/A - not hiring yet.
    12. No - again, impossible in a 1-person shop. Also, very little of what I do is UI design.

    The problem with the Joel Test is that it's geared specifically towards organizations like his.

  • (disco)

    OMG. You can get lower score than we have. We have Joel score 1. Because at least we use the best hardware, IDEs and dev frameworks money can buy. Okay, it's a shaky 1: why wouldn't "the best tools money can buy" include something like Jasmine, nUnit and Selenium?

  • (disco) in reply to Antarctica

    If you're not using source control, then you're clearly not using the best tools money can buy. So you can't have 1 :stuck_out_tongue:

Leave a comment on “The Record Setting Score”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article