Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Monday October 10 2016, @04:37PM   Printer-friendly
from the if-only... dept.

There is an interview with Joel Spolsky on GeekWire which reports that companies should Just shut up and let your devs concentrate:

If you want to attract and keep developers, don't emphasize ping-pong tables, lounges, fire pits and chocolate fountains. Give them private offices or let them work from home, because uninterrupted time to concentrate is the most important and scarcest commodity.

That's the view of Joel Spolsky, CEO of Stack Overflow, a popular Q&A site for programmers, who spoke this morning at the GeekWire Summit in Seattle.

"Facebook's campus in Silicon Valley is an 8-acre open room, and Facebook was very pleased with itself for building what it thought was this amazing place for developers," Spolsky said in an interview with GeekWire co-founder Todd Bishop. "But developers don't want to overhear conversations. That's ideal for a trading floor, but developers need to concentrate, to go to a chatroom and ask questions and get the answers later. Facebook is paying 40-50 percent more than other places, which is usually a sign developers don't want to work there."

[Continues...]

Spolsky, who in 2011 created project-management software Trello, said the "Joel Test" that he created 16 years ago is still a valid way for developers to evaluate prospective employers. It's a list of 12 yes-no questions, with one point given for every "yes" answer:

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

"The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time," Spolsky said when he created the test. He said that remains true today.

How well does your organization support its developers? If new or better equipment would improve your productivity, is it made available to you? How is your work environment? How well does your organization score on the 12-point "Joel Test"? What is the biggest thing blocking your company from improving?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Interesting) by Anonymous Coward on Monday October 10 2016, @07:38PM

    by Anonymous Coward on Monday October 10 2016, @07:38PM (#412599)

    I think the public would benefit greatly if all of your listed systems were open-sourced. Currently as a society we have thousands of different and incompatible implementations of such systems. If we opensource it all, and started sharing code, we could collectively converge on single good implementations with fare more auditing than any independent closed system could afford. It would also make it much easier to hire people to work on such systems (there would be a large pool of people already up to speed, and good docs and a community to help new devs, as well as much higher code quality, and no need for NDA_s, or crappy private VCS_s).

    I would trust a world wide open source project with tons of money funding its audits and tests over some city's one off project maintained by someone who took over a code base he has no idea how it works that was written 30 years ago in a language no one uses any more.

    Security through obscurity might help a tiny bit against outside threats, but our main problems are internal failures, and systemic design problems (like connecting the wrong networks together) which would be mitigated by having it as an open source project where people could point out such problems. We can do open source security: its not impossible.

    Starting Score:    0  points
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  

    Total Score:   1  
  • (Score: 1, Touché) by Anonymous Coward on Monday October 10 2016, @08:03PM

    by Anonymous Coward on Monday October 10 2016, @08:03PM (#412608)

    Let's eliminate physical security by obscurity, wow!. You know I always wondered how that dude Elliot found the time to research the insider details of public utilities in order to hack everything so easily. Now it's so clear. Mr Robot lives in the fantasy world you describe where police departments and prisons and phone companies just open source everything.

    I'm gonna go post my backup schedule and the locations of all my backups on my blog now. Surely nobody would want to destroy all copies of my backups at once. So the locations of my backups don't need to be secret.

    • (Score: 2) by urza9814 on Wednesday October 12 2016, @11:05PM

      by urza9814 (3954) on Wednesday October 12 2016, @11:05PM (#413685) Journal

      You know I always wondered how that dude Elliot found the time to research the insider details of public utilities in order to hack everything so easily.

      What, the floor plans of the building and such that they used to get inside and plant their Pi? Architectural diagrams aren't code, so "open source" doesn't really apply there. Also that information is often public already here in the real world. And even if it wasn't public, thousands of people would still have had access to it. If you consider "they'd have to bribe a janitor" to be good security, you're gonna have some bad surprises coming...

      I'm gonna go post my backup schedule and the locations of all my backups on my blog now. Surely nobody would want to destroy all copies of my backups at once.

      Also not code, so "open source" doesn't really apply. It's not "security through obscurity" to keep your encryption keys secret either. The point isn't that EVERYTHING must be open, the point is that the secrets should be as small as possible. A secret password with a public algorithm almost always works better than a secret password with a secret algorithm, because you're only as secure as the weakest link, so you probably want to choose an algorithm that's been researched for flaws for decades rather than something you just threw together overnight.

      And if your backups get destroyed, that really isn't a security issue anyway, that's a data integrity or accessibility issue. It would actually *improve* the security of that data -- we still haven't managed to crack the 'big freakin' bonfire' method of encryption.

      So you aren't arguing for security through obscurity, you're arguing for accessibility through obscurity. Which might be a valid tactic actually, although I'm having trouble coming up with any examples that wouldn't be fairly trivial to defeat or cause more harm than good (ie, you can't take out a website by cutting a wire if you don't know which wires to cut...but that seems rather unlikely to begin with compared to maintenance cutting the wrong wires because the damn things aren't labeled clearly!)

  • (Score: 3, Insightful) by Aiwendil on Monday October 10 2016, @09:18PM

    by Aiwendil (531) on Monday October 10 2016, @09:18PM (#412644) Journal

    No, it wouldn't - uncertified coders and programmers are a pest in those fields.
    And higher code quality? I kinda doubt that - degraded cables (fatigue due to temperature variations) are more common than software errors in those fields and - excepting IFFs - no NDAs either).

    Also - best practice and common solutions makes the nasty assumption that the underlying hardware are the same (or suitable) which very often are not the case. (Even six months difference in deployment can mean a vendor has gone out of buisness, or that new cable qualities are in use, or an insulator has been outlawed, or a poltician has decided on a new standard. Once you leave the world of pure software such things causes a lot of variations)

    The [non site-specific] auditing would also be close to useless unless all variations are checked for and that would be impossible due to it being hard to foresee laws and politics and technological advances.

    I actually would trust open source less than industrially verified one-off code with proper documentation (what would you rather see control the aiplane you're on - boeing/airbus internal verified code or systemd ;)
    (Or a bit more serious - who would you rather make the controller for the 200kV switch - a company with 60+ years experience and database of issues or a mix of whoever stumbled in on its github-page?)

    And no, this isn't as much security through obscurity as it is that we don't want people to even considering doing anything without consulting, writing and supplying proper documentation.

    • (Score: 3, Interesting) by hendrikboom on Tuesday October 11 2016, @05:54PM

      by hendrikboom (1125) Subscriber Badge on Tuesday October 11 2016, @05:54PM (#413027) Homepage Journal

      I actually would trust open source less than industrially verified one-off code with proper documentation

      I actually would trust industrially verified open-source code with proper documentation even more.