Comments on: When Is The Release?

By: Charlie Wood

Charlie Wood — Wed, 07 Jan 2009 01:55:50 +0000

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

By: Tony Casson

Tony Casson — Wed, 07 Jan 2009 01:55:50 +0000

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.

By: Don Jones

Don Jones — Wed, 07 Jan 2009 01:55:50 +0000

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.

By: John May

John May — Wed, 07 Jan 2009 01:55:50 +0000

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.

By: Nick

Nick — Wed, 07 Jan 2009 01:55:50 +0000

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

By: Charlie Wood

Charlie Wood — Wed, 07 Jan 2009 01:55:50 +0000

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

By: just.a.guy

just.a.guy — Wed, 07 Jan 2009 01:55:50 +0000

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.

By: Mitchell Ashley

Mitchell Ashley — Wed, 07 Jan 2009 01:55:50 +0000

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.

By: todd_vernon84

todd_vernon84 — Wed, 07 Jan 2009 01:55:50 +0000

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

By: rick_leach4794

rick_leach4794 — Wed, 07 Jan 2009 01:55:50 +0000

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.

By: kimm_viebro1980

kimm_viebro1980 — Wed, 07 Jan 2009 01:55:50 +0000

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...