The advantages of being part of a large anti-spam company

Sometimes I moan about the difficulties of being part of large company in the time it takes to get things done, but it has its advantages.

As part of a small company, stuff is often done ad hoc.  People write spam rules, write little scripts to do stuff and the processes aren't really defined.  Microsoft is not like that at all, at least with the undefined processes part. 

Perhaps the biggest difference is that in a large company, there is a very well defined software development life cycle.  This is something that I learned about in university and it was an abstract concept.  Well, now I'm living it.  The cycle goes something like this:

  1. I come up with an idea
  2. A requirements spec is written
  3. A dev spec is written
  4. Coding begins
  5. A test spec is written
  6. Code complete hits, testing begins
  7. Security reviews are undertaken, sometimes before the previous step and sometimes after
  8. Bug fixes are completed
  9. Simultaneously, interaction with Operations begins, as they will be deploying the stuff; a deployment schedule is created
  10. Deployment documents are written
  11. Staging begins (different than Test)
  12. Staging ends and optionally, pre-deployment
  13. Deployment

This is a very long process.  As part of a small company, coding took up the bulk of a product's life cycle.  Now, it's maybe 5-10% of the entire phase.  Each review typically goes through a couple of iterations.  Now you may be wondering what the advantage is this process, and the answer is that if there's an established process with checked-in and managed code, it is way easier to prevent bugs before they occur.  It's easier to manage the code afterwards and it's easier to manage the code when people leave.

With lots of little scripts kicking around, when somebody leaves or goes on vacation and something goes wrong, it can take an eternity for someone else to figure out what is going on with the stuff that is broken.  In other words, with managed code, maintenance costs come way down. 

I am finding that much of our internal infrastructure becomes much more stable when we have designed around the process rather than ad hoc.  Even in the realm of anti-spam where quick reaction time is required, if the architecture is stable it allows you to avoid having to fix bugs in your tools and the stuff you actually use to fight the spammers.

Comments (2)
  1. Norman Diamond says:

    "it is way easier to prevent bugs before they occur"

    It is?  #6 looks to me like this:

    6a. Code complete hits.

    6b. Brick wall.

    6c. Testing begins.

    When steps 4 through 6a can’t fix bugs that were created in step 2, you get disasters, some of which are pretty famous.  When steps 6c through 8 can only fix a tiny portion of the bugs that were created in steps 4 through 6a, and they can’t fix bugs that were created in step 2, you get disasters, some of which are pretty famous.

    My latest project was pretty simple.  Simple as it was, I asked around 15 questions about the spec and suggested 15 possible adjustments.  The customer agreed with all of the suggested adjustments.  Of course customers vary and some do prefer disasters.

Comments are closed.

Skip to main content