Brad's Books and Organizations

Books

Books

Organizations

Organizations

Hi, I’m Brad Feld, a managing director at the Foundry Group who lives in Boulder, Colorado. I invest in software and Internet companies around the US, run marathons and read a lot.

« swipe left for tags/categories

swipe right to go back »

When Is The Release?

Comments (11)

A company I have a small investment in has been struggling to get the most recent version of their software shipped.  A few weeks ago I ran into the CEO who grabbed me and said "we are almost ready to go live."  I looked at him and said "when is the release."  His answer was "Friday."

I gave him a Bronx cheer and said "when on Friday?"  He looked at me like I was an alien.  I clarified – do you mean "12:01am on Friday, 4:59pm on Friday, or 11:59pm on Friday."  I then clarified some more: "and I mean in Mountain time."  We agreed that 11:59pm on Friday was a good time (which they missed, but they got it out a few days later.)

At my first company (Feld Technologies), our client base got to the point where we were often doing multiple releases of different software on a weekly basis (we were a custom software company but used a very traditional software engineering approach to our projects.)  For a long time, we used dates to mark releases (e.g. "Friday.")  After way too many 11:59pm releases (where our clients definitely were not sticking around the office to wait for us) and missed Fedex deadlines (this was back when you had to Fedex the disks to the clients in another state because modems were too slow to transmit the files), we learned that a release has both a date and a time.  We also learned that the external release is – at the minimum – date + 1 of the "internal release" especially on systems with live data.  We also learned that the only appropriate days of the week for a release are Tuesday, Wednesday, or Thursday.  I’ll let you guess as to why this is.

As I work with new startups and first time entrepreneurs, I see people learning this lesson over and over again.  I think it’s just going to be part of the endless education of new software entrepreneurs that you never really learn until you are in the real world.

  • http://www.venturedeal.com Don Jones

    FWIW, updates for my venture capital database must go live before noon – so my programmers have the rest of the day to be on emergency stand-by…In addition, we have two staging areas – the first one is on the developer's web machine and the second is on the live servers but not the live site. Once testing is done on both, the code gets switched live.

  • http://spanningsync.com Charlie Wood

    Why would you come up with an arbitrary release date (and time!) and then hold yourself to it? In my opinion, software should be released when it's ready, and being able to recognize when that is should be a core competency of any software company.

    -c

    • http://falseprecision.typepad.com/my_weblog/ Todd Vernon

      Charlie, I few things have stuck with me through the years. If everyones in charge, knowone is in charge, and, if you don't set a date and time for your release its never done. In fact its purely anecdotal, but I'm quite sure if you don't set a milestone you are going slower then is possible. My $.02

    • Rick Leach

      I know a development team that always released at 2pm. They just didn't say which day, month or year (or time zone for that matter). They never missed a deadline ; )

      Seriously this is an age old problem. If you're too aggressive on the deadline, the quality can suffer and if you don't release until the quality is “right” then it won't get out in a reasonable time frame. The best organizations achieve an incredible balance when all parties understand and focus on the possible impact of the release on both customers and the tech support team.

  • http://tintos.blogspot.com Tony Casson

    I have managed to (mostly) corral my current B to C company's external releases – which, from where I sit, functions as the hand-off from development to operations – to Tuesdays and Thursdays at 3:00 PM MT. However, back at Raindance, we began all our public releases at 10:00 PM MT on Friday. We were of course a B to B company and our traffic load was considerably lower on the weekends. Tuesday – Thursday never would have worked there as we needed the weekend to stabilize before going into high volume periods. Thus, I offer the corollary to the the Tuesday-Thursday theorem. Release on Tuesday-Thursday if your traffic is spread evenly throughout the week. Otherwise, release right before your slowest period of time.

  • http://www.rallydev.com John May

    What about agile concepts of never missing a release. Rally might be able to help some of these companies be a lot more responsive, with higher quality and more productive along the way. Check out BMC's stock since they became a Rally customer compared to other tech companies. Maybe we should have an agile index fund.

    It works for big companies and small alike.

  • Nick

    Feldforthought.com … catchy name if you ever want to seperate the blog site from this site. As long as you aren't worried about Kang and Kodos (1) scouring the internet for their next meal.

    (1) http://en.wikipedia.org/wiki/Kang_and_Kodos

  • http://spanningsync.com Charlie Wood

    Todd,

    I didn't say that everyone should be in charge. Ultimately, someone has to be responsible for deciding if a release is ready. But to me, that decision should be based on the status and quality of the software, not some arbitrary predetermined date and time. Different stroke for different folks I guess, but personally I'd rather buy software that some responsible party had deemed “ready” rather than something that was current as of an arbitrary time.

    Cheers,
    Charlie

    • just.a.guy

      in the context of venture-backed startups, which is what Brad's talking about, that kind of thinking can kill a company.

      It's akin to answering the questions: “how much capital should we budget for development of v1, first launch, and early adoption measurement? and therefore how much should we raise?” with the answer: “whatever it winds up costing”

      oops.

  • http://theconvergingnetwork.com Mitchell Ashley

    Friday is the new Monday.

    Another common event is that Friday software releases become “Monday before 8 a.m.” releases. To co-opt a common saying, Software Happens.

    If the project plan puts the release date on a Friday, just make it Monday as the team will likely want the weekend if needed. The exception is Holiday weekends when folks likely have other plans.

  • Kimm Viebrock

    As Charlie mentions, it's not generally prudent to release software before it's ready. As others have mentioned, it doesn't work to wait for 'perfect' either… and irrespective of both is Brad's claim, which I wholeheartedly support, that there is an optimal time to release; a time that will increase your likelihood of success and happy customers and decrease the number and magnitude of headaches.

    I would assert that one of the best people to consult when looking for the right balance between these considerations is the person who knows your customer service/technical support operation inside and out. That person will be sensitive to the developer resources needed immediate post-release and the likely impact on customers. That person will have a good historical sense of your business to know when the least disruptive times would be to launch and factor that in with the other considerations.

    Ultimately, there will be a day of the week and time of day – perhaps day and/or week of the month, too – when it will be best to schedule the release. Your tech support people can also help tell you whether it's ready for release. And if it's not, then Charlie's right, don't just push it out according to some arbitrary schedule; wait until the next good launch window.

    A steady stream of calls is far less expensive for your organization (in actual dollars or customer impact or both) than a sudden glut of calls resulting from confusion or broken code. And technically speaking, if you break something in a new release, those costs are development costs, not support costs.

    As an example for how timing of a release can matter, I had someone ask me last November to provide some insights on support costs for a new gaming joystick then in manufacturing, as that's something I do for organizations who DON'T have an expert technical support person in-house. My response was that it entirely depends on whether they were intending to release in early to mid-December or whether they'd be releasing in January or later.

    I'll let you guess as to why that is…

  • Charlie Wood

    Why would you come up with an arbitrary release date (and time!) and then hold yourself to it? In my opinion, software should be released when it's ready, and being able to recognize when that is should be a core competency of any software company.

    -c

  • Tony Casson

    I have managed to (mostly) corral my current B to C company's external releases – which, from where I sit, functions as the hand-off from development to operations – to Tuesdays and Thursdays at 3:00 PM MT. However, back at Raindance, we began all our public releases at 10:00 PM MT on Friday. We were of course a B to B company and our traffic load was considerably lower on the weekends. Tuesday – Thursday never would have worked there as we needed the weekend to stabilize before going into high volume periods. Thus, I offer the corollary to the the Tuesday-Thursday theorem. Release on Tuesday-Thursday if your traffic is spread evenly throughout the week. Otherwise, release right before your slowest period of time.

  • Don Jones

    FWIW, updates for my venture capital database must go live before noon – so my programmers have the rest of the day to be on emergency stand-by…In addition, we have two staging areas – the first one is on the developer's web machine and the second is on the live servers but not the live site. Once testing is done on both, the code gets switched live.

  • John May

    What about agile concepts of never missing a release. Rally might be able to help some of these companies be a lot more responsive, with higher quality and more productive along the way. Check out BMC's stock since they became a Rally customer compared to other tech companies. Maybe we should have an agile index fund.

    It works for big companies and small alike.

  • Nick

    Feldforthought.com … catchy name if you ever want to seperate the blog site from this site. As long as you aren't worried about Kang and Kodos (1) scouring the internet for their next meal.

    (1) http://en.wikipedia.org/wiki/Kang_and_Kodos

  • Charlie Wood

    Todd,

    I didn't say that everyone should be in charge. Ultimately, someone has to be responsible for deciding if a release is ready. But to me, that decision should be based on the status and quality of the software, not some arbitrary predetermined date and time. Different stroke for different folks I guess, but personally I'd rather buy software that some responsible party had deemed "ready" rather than something that was current as of an arbitrary time.

    Cheers,
    Charlie

  • just.a.guy

    in the context of venture-backed startups, which is what Brad's talking about, that kind of thinking can kill a company.

    It's akin to answering the questions: "how much capital should we budget for development of v1, first launch, and early adoption measurement? and therefore how much should we raise?" with the answer: "whatever it winds up costing"

    oops.

  • Mitchell Ashley

    Friday is the new Monday.

    Another common event is that Friday software releases become "Monday before 8 a.m." releases. To co-opt a common saying, Software Happens.

    If the project plan puts the release date on a Friday, just make it Monday as the team will likely want the weekend if needed. The exception is Holiday weekends when folks likely have other plans.

  • http://intensedebate.com/people/todd_vernon84 todd_vernon84

    Charlie, I few things have stuck with me through the years. If everyones in charge, knowone is in charge, and, if you don't set a date and time for your release its never done. In fact its purely anecdotal, but I'm quite sure if you don't set a milestone you are going slower then is possible. My $.02

  • http://intensedebate.com/people/rick_leach4794 rick_leach4794

    I know a development team that always released at 2pm. They just didn't say which day, month or year (or time zone for that matter). They never missed a deadline ; )

    Seriously this is an age old problem. If you're too aggressive on the deadline, the quality can suffer and if you don't release until the quality is "right" then it won't get out in a reasonable time frame. The best organizations achieve an incredible balance when all parties understand and focus on the possible impact of the release on both customers and the tech support team.

  • http://intensedebate.com/people/kimm_viebro1980 kimm_viebro1980

    As Charlie mentions, it's not generally prudent to release software before it's ready. As others have mentioned, it doesn't work to wait for 'perfect' either… and irrespective of both is Brad's claim, which I wholeheartedly support, that there is an optimal time to release; a time that will increase your likelihood of success and happy customers and decrease the number and magnitude of headaches.

    I would assert that one of the best people to consult when looking for the right balance between these considerations is the person who knows your customer service/technical support operation inside and out. That person will be sensitive to the developer resources needed immediate post-release and the likely impact on customers. That person will have a good historical sense of your business to know when the least disruptive times would be to launch and factor that in with the other considerations.

    Ultimately, there will be a day of the week and time of day – perhaps day and/or week of the month, too – when it will be best to schedule the release. Your tech support people can also help tell you whether it's ready for release. And if it's not, then Charlie's right, don't just push it out according to some arbitrary schedule; wait until the next good launch window.

    A steady stream of calls is far less expensive for your organization (in actual dollars or customer impact or both) than a sudden glut of calls resulting from confusion or broken code. And technically speaking, if you break something in a new release, those costs are development costs, not support costs.

    As an example for how timing of a release can matter, I had someone ask me last November to provide some insights on support costs for a new gaming joystick then in manufacturing, as that's something I do for organizations who DON'T have an expert technical support person in-house. My response was that it entirely depends on whether they were intending to release in early to mid-December or whether they'd be releasing in January or later.

    I'll let you guess as to why that is…

Build something great with me