Why small software companies are more dynamic

babel1997.jpgI’ve read the post from Eric Lippert on Fabulous Adventures In Coding , describing what’s the “real work” behind 5 minute of development at Microsoft:

  • One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.
  • One program manager to write the specification.
  • One localization expert to review the specification for localizability issues.
  • One usability expert to review the specification for accessibility and usability issues.
  • At least one dev, tester and PM to brainstorm security vulnerabilities.
  • One PM to add the security model to the specification.
  • One tester to write the test plan.
  • One test lead to update the test schedule.
  • One tester to write the test cases and add them to the nightly automation.
  • Three or four testers to participate in an ad hoc bug bash.
  • One technical writer to write the documentation.
  • One technical reviewer to proofread the documentation.
  • One copy editor to proofread the documentation.
  • One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc.
  • Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows.The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem.
  • A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President.
  • And I garrantee this is not a joke…this is true. During my short carrier in software development, I’ve seen all size of software companies: from 6 to more than 7000. I’ve seen this only in large companies, so what startup (I guess we can also apply this to Open Source) companies are doing to handle this? They simply dont care and don’t do it.

    Jeff Atwood comment also on this in his post Is Eeyore Designing your software saying that startup and Open Source do not have all this development process.

    What is the rational for such heavy process? I guess at least 2 reasons: type of customer and sofware development vision.

    Some of the large companies are targeting large customer (Fortune 500 for example) to sign for large deals. These customers are world wide companies, so the localization is key to close a deal. The documentation is also important. They also emphasis standards in their selection criteria as 508 compliance for US governement. Thay also have technical schemas as for example allowed operating systems or supported application servers.

    The software development vision of large software companies is also an industrial view: be predictible through control and strong processes. It’s very common to hear people saying:

    • You can’t manage what you can’t measure.
    • You can manage quality into a software product.
    • Software needs more methodologies.

    These are part of the fallacies highlighted by Jeff Atwood (yes again) in his impressive post on Revisiting The Facts and Fallacies of Software Engineering.

    I had a boss who was questioning : “Why building software is no as simple as making a car?”. He was refering to the ability to deliver a product on time with good quality…which is very rare in software delivery. First, making a car is not so easy, but I agree from an external point of view, it seams more predictable et cars more robust than softwares. The main reason is that software development echosystem is evolving a lot and quicker than car making technologies. The tools are always changing, every month some new technologies appears, even languages, methodologies also are evolving a lot. To gain predictibility, large software company are enforcing processes that decrease drastically productivity.

    Knowing early lose for late win

     I see often managers stretching their team to acheive goals as early as possible without any middle term or long terme appraoch.

    Achievement is important but you have to be less productive at some point –take a breath — to get better acheivement latter. Here are some example:

    • training and team’s skills ehancement,
    • change a tool if you are reaching the edge of it
    • do not assign storyes/task on a specific area always to the same developer for productivity reasons
    • reduce tests (automatic or not) and focus exclusively on coding