Big Step/Small step

Cyrus Blather Big Step Small step | bar stools

Cyrus Blather Big Step Small step | bar stools — Fri, 19 Jun 2009 09:33:41 GMT

PingBack from http://barstoolsite.info/story.php?id=2308

Cyrus Blather Big Step Small step | internet marketing tools

Cyrus Blather Big Step Small step | internet marketing tools — Tue, 16 Jun 2009 08:00:25 GMT

PingBack from http://einternetmarketingtools.info/story.php?id=12620

thank you

Mishel — Wed, 24 Aug 2005 20:14:06 GMT

Your site is realy very interesting. http://www.bignews.com

re: TweakC#

Cyrus' Blather — Thu, 11 Nov 2004 00:17:00 GMT

re: Big Step/Small step

Shital Shah — Mon, 08 Nov 2004 08:36:00 GMT

I'd been similar situation with my PM an year back. Our company has a policy not to ship anything until not only every feature is incorporated but also a full QA cycle is run AND there are absolutely no bugs left to fix. If we haa scheduled last build on Friday and if QA comes on with one-in-a-million-year issue on Sunday, whole schedule will be posteponed. To make this even worse, after we have releasd the product to customers and then if you find bug, we weren't allowed to fix it. In case if tremendous pressure builds up, they will ask us to branch out whole project (literally 30+ component sub-projects), make a change and run ENTIRE QA cycle all over again for weeks. The product wasn't used for mdecal or life critical or aviation or financial banking stuff, but they did all of these because they wanted a "solid" bug-free product. This, unfortunetely, isn't realistic. I'd been aggressively trying to push incremental deployment and automatic on-demand updates model, but they just didn't seem to get over their "perfact product" dream.

I absolutely belive in evolving product model. Many times what customer wants is fast turnout, something real to play with raher than waiting for years to see final product and then again another years to more features.

Mathematically, its impossible to have solid product if the scale is large without puting tremendous time and effort - which in moern markets might just proove too late.

Many MS products falls in to this category. A new version of WIndows or Office takes years and years to see the customer.

I guess key is the number of intruptive and data-loss bugs. The intruptive bugs are those which will intrupt *usual* way of using the software and make cutomer to call support. If these two types of bug count is 0, product should get out of door with monthly or even weekly synking with new builds. Also these builds should be available on Internet rather then retail boxes to make sure people who are downloading it have ability to update in future. For retail boxes, I still believe it should be "solid" version of the product. However this is more applicable to non mission citical direct applications in domains like militery, airospace, banking, medical etc. All others can and should follow evolving builds model.

re: Big Step/Small step

Vince P — Fri, 15 Oct 2004 18:29:00 GMT

I'm still waiting for the bugs in VS2003 to be fixed

re: Big Step/Small step

Cyrus Najmabadi — Wed, 13 Oct 2004 04:25:00 GMT

Mark: "Thank you, Thank you, Thank you - there are a lot of fixes (big and small), that I'm waiting for in the Visual Studio environment. Decuple framwork revisions from tools revisions and have releases evry 6-8 weeks."

I'd definitely like that. It would be nice to be able to ship not connected to the runtime. And it would be even nicer to ship tools that weren't so tied to the IDE. not yet though. Sigh...

"As for the concerns about frequent releases - look into any of the agile methodologies (XP, Crystal Clear, ...), they encourage it. It certainly seems to work for Eclipse."

Our team has been focussing a lot on agile and XP and we'd like to move completely over to it. Jay http://blogs.msdn.com/jaybaz_MS talks about it a fair bit and is pretty passionate about it.

re: Big Step/Small step

Cyrus Najmabadi — Wed, 13 Oct 2004 04:21:00 GMT

Jeff: "I'd like to find the person responsible for "Elvis" and "Mort" so I can kick them squarely in the nuts. Whoever you are, I totally blame you for this sad state of affairs.

Incremental compilation and Edit-And-Continue are important for every developer, not just "marketing persona A". "

The personas were not what dictated what features the languages got. C# didn't get incremental compilation and EnC because someone thought that those features were unimportant. C# didn't get those features because it was felt (especially after communicating with the community) that refactorings were more important and that given our limited resources it was right choice.

We dont' sit here twiddlign our thumbs (well, sometimes when a long link is happening) during te product cycle. Every day is jam packed and we're working darn hard :-)

FWIW, incremental compilation and EnC are not simple problems. If i could come in on a weekend and get it done i most certainly would. However, they're features that would take a team a significant amount of time and which would add ton of risk.

How do you implement incremental compile? Will it scaled to projects with 10s or 100s of MB of code? How do you test it? etc. etc.

When C# was getting created it was decided for simplicity and speed to go with the current architecture. I believe that at that time it was a reasonable choice to make (even though i disagree with it), but we're definitely feeling the effects now. And, as i said before, it's very much something i want us to be working on.

Just to make it clear: It's not marketing :-)
We're just not supermen, that's all.

re: Big Step/Small step

Cyrus Najmabadi — Wed, 13 Oct 2004 04:14:00 GMT

ChrisBro: "The biggest problem with doing releases every few weeks is that it's difficult to do anything more significant than small bug fixes or trivial features. Even a release every few months gives you about 8-10 weeks of code then a bunch of stabilization time. You never get to do refactoring or cleanup because you're always in crunch mode to ship. There are no beta releases where you can decide something just didn't work well and pull it.

So while you get to spin on quick fixes, you don't get to do the really exciting new stuff."

I agree/disagree. I think you could do staggered released where you do work on some pretty big things (like generics), that require a lot of coordination to get right. but at the same time you could be producing your incremental work as well.

re: Big Step/Small step

Cyrus Najmabadi — Wed, 13 Oct 2004 04:12:00 GMT

Drazen: I agree. There are lots of little features I want to do that we just don't have time to do now and i don't want to have to wait years more until they're released.