Time for Hotfixes?

[DaveDaveDave]

@JohnOnKeyz

Nightly or weekly builds is a hard transition if it is not already in place (Mozilla had this from the start, but a lot of other companies work in a different way). Not to mention, it is risky, and would have to be installed at the discretion and responsibility of the user. For this kind of thing, it would be difficult to align with product stability and reliability… because a bad bug fix could potentially cause all kinds of problems on both the user and company level.
Cheers!

Agreed - there’s a lot to this - it would probably require major methodology shifts in engineering at Steinberg. I earn my living code too - more in the middle-ware space though. I have no idea if they’re practicing any kind of agile development, but I’m certain they don’t do enough test-first-design, where frameworks live around the code for unit testing.
I wanted to share a decade old anecdote, where we built one of the best test environments I’ve heard of, and it’s a model that I think would probably work very well for Steinberg.
Where upon every single checkin, the entire product was built, the installers were built, product installed, and then the final product automated to run against an “end-game” round of integration tests. This product was actually a server and client java code generation tool for web-services, including j2ME code generation for smart-phones - so the integration tests weren’t exactly trivial. The generated code was compiled on multiple platforms and then ran live interoperability tests across the internet, interfacing our own test servers and with all of the other vendor’s online test implementations of the SOAP specification. The entire checkin-build-buildinstaller-install-generate-compilegeneratedcode-run-report cycle ran several times a day, anytime anyone checked in code!
Furthermore, this team consisted of only 10 or so people working in remote locations (East Coast US, West Coast, Australia and Ireland!). Automation was the key - if a checkin broke any unit or integration tests, an shameful email with the developers name and the offending code changes was sent around the world
To get a team to this level is NOT easy - and I haven’t seen it to that degree ever since. IMHO, the hardest part is getting buy-in from team leadership and from product management. Developers gripe about having to handle so much “additional” test code, but it’s not as hard as convincing management that the extra up-front overhead on infrastructure is worth it.

Whew - sorry for the ramble… back to my code.

Dave

[DrWashington]

Well, damn, DaveDaveDave, that was a helluva rant! I thoroughly enjoyed it. I used to do a bit of coding many moons ago, and enjoyed myself quite a bit… don’t know why I quit… oh, yeah I do… debugging keeping me up for sometimes days in a row when I was under the gun.

This stuff is not easy by any means, and I can empathize with our intrepid coders at Steinberg 100%. But, I still think that more rapid bugfix deployment is essential in today’s fast moving techno-landscape. I think C.O.C.K.O.S. (<–like that, Steinberg wordfilter?) has the right idea in this regard. Their software is incredibly powerful and I’m liking it more and more as time goes on, but I just know Cubase too well to seriously consider switching–plus, their are things that Cubase is just far too good at to ignore, so it beckons me back time and again.

I hope this will continue, and I hope Steinberg will see the light and find a way. I know there is a way! Faster, even “beta” updates would be welcome if it meant crucial features would be immediately available.