All about the Kinder™
You’re Doing it Wrong
By Adam Kinder on Apr 7, 2008 in
A software development lifecycle accomplishes a few things, one being that your product actually gets into the hands of customers. Apparently quite a few Zuckerburg CEOs seem to think it means that you rename and reversion your product 80 times for your own delight and glee.
Yes, I’m aware that I’ve done the exact same thing. First there was Serenity Project Manager. Then Serenity Enterprise Server. Then Rhapsody. Then Synapse Publisher. Then SerenityAP. At least I stick with the Serenity name.
The difference being that two times, we were legally obligated to change the name due to trademark issues, and Serenity Project Manager is still developed especially for several large companies and websites. Due to time constraints and contracts, we decided to work especially with those companies on Serenity PM, and stop selling it to the public.
Fast forward to today, and now we’re offering up some community pieces, such as the free blog software and CMS, and the more expensive Enterprise suite that is aimed to replace Serenity PM.
Where the software lifecycle comes into play is the fact that even after renaming and version changes for Serenity, it still has followed a lifecycle from design, to develop, to test, to maintenance. Our SDM and lifecycle hasn’t changed since we first started the company in 2006, and although I’ve had to stray from it a few times in the past two years, SerenityAP and Enterprise has undergone the full lifecycle ( save for maintenance, that comes next ), and it’s paid off in more ways to one. Namely, it’s actually going to be released on time, with proper documentation, and it’s not something we’ve been talking about for eight years and shown 0 results for.
I was poking around over the weekend and came across one such example of a failed SDM. The lead programmer has a serious air about him, which is why it was funny that he throws his development into the wind and sees where it lands. Naturally the five different projects that the company develops have yet to see a public release, but have somehow been notched up to version 1.2 The question is, what the hell happened to 1.0? And 1.1?
For those of you out there thinking of jumping into startup land, or just want to release your latest project to the world, here are four important development stages to keep in mind:
Design
Although it should be a given, the design phase of a lifecycle is one of the most important stages in the life of a software product or service. Skipping over the design phase is a great way to get a product into beta faster, but will also plague you with feature creep and some nice unforeseen bugs. This is especially true when starting the lifecycle over for a new release. If you skip the design phase for upgrades, expect some angry customers, especially after a missing code block eats their valuable data.
Development
This step is required. Well, for those of us that actually get a product to market. Development itself consists of a few sub stages, including feature gathering, wireframing, and others. That’s another topic for another day.
Test
This is another stage that is often skipped, especially in the day and age of Web2.0 It’s much easier to just slap a “BETA” star tag on the product/service than putting it under stress and usability testing.At E29 we use JMeter from the Apache group for the stress testing, and a detailed test plan to work out any last minute bugs. While user beta testing is important and useful, generally we get our best results from internal testing.
Documentation should be prepared at this stage. Many companies and developers make the mistake of documenting while developing or even designing. This is pretty much useless, as products tend to change and evolve even during the development phase.
Maintenance
Ah, the end of the road. The product has been released, and now it’s maintenance time. Generally you will also start a parallel lifecycle for your next major release, starting back at the design phase. For the maintenance stage, you will kick back to developing, then testing, and then releasing the new patch.
Obviously, these stages are pretty basic and easy to follow. You’d be surprised how much faster your product cycle will go if you just follow a standard development lifecycle.
That is very much the truth about “web 2.0″ crap. I do not remember what site I was at yesterday, but it said “beta” on it. I visit at least a few web applications a day that have “beta” slapped on them. Speaking of which, GMail still says “beta”. Beta must be the new term for going gold.
This entry coincides with this post ( http://forums.invisionpower.com/index.php?showtopic=225926&view=findpost&p=1713847 ) pretty well, and while we’re probably not the target of the post, I can’t help but think we inspired it just a little.
Hey, Adam. I’m a fan of you and E29 as well as a (mostly) silent lurker of your blog.
I just want to clarify that at Omega Vortex, we’re very much committed to exercising the entire software development process on all of our products. We’ve put a lot of careful thought and planning into our process. Starting from the top and coming down, we obviously use Source Control, of the Subversion variety. Our build server produces nightlies of all of our projects that are unit tested and deployed to our development environment. It also supports Continuous Integration through CruiseControl and phpUnderControl so that individual commits are also run through unit testing and deployed to the development environment.
After we finish our development cycle, a build is selected and promoted to our testing environment where our QA Manager puts together a test plan for the application. Once QA is done with a significant amount of internal testing, we should be about at “Beta 2″ or “Beta 3″ by this point. A private preview release is put out for customers to examine and report back on issues they find. Feature lock has been in place since long before now, so the focus is entirely on finding and squashing bugs.
After more beating by QA and the group from the private preview release, we then move onto our Theta and Sigma release stages. These are the equivalent of “Release Candidate” for most places, but Theta is a lot looser than Sigma. During the Sigma release stages, only bugs that are specifically marked as a P1 or a High-Urgency P2 will be fixed, to ensure the minimal impact on the rest of the app. Low-Urgency P2’s and lower are pushed to a point release to be made within a couple weeks after the main release to resolve any outstanding issues.
Then, of course, comes the maintenance cycle and the customer and market requirements gathering for the next release. And the cycle begins anew.
Our problem, being a small start-up bootstrapping from my own personal income, is that we have to take paying gigs over our own software development. That’s why releasing a product is so hard, right now. The consulting gorilla on our back is getting lighter as we take in more developers and we’re doing internships with the local colleges and universities to give students some practical experience in development with mentoring from our in-house professionals. A win-win situation for all.
Again, none of that entry may have been aimed at us, but I just felt the need to clarify, since it was such a coincidence that the two posts lined up so well.
Have a good one.
Jeremy,
Thanks for the comment. I actually writeup these entries a few days in advance ( or the night before, depending on how much coffee I’ve had
) and they auto publish during high traffic times, so it’s just a coincidence with the forum post.
My concern on the forum post was that it seemed like you were wrapping Converge itself inside another authentication layer, which may or may not be the case. Honestly I’m still scratching my head on the whole Converge bit anyway, and why IPS would bother with creating another login layer instead of using OpenID or something similar.
Ah, I see. Very cool.
Like I mentioned on the forum, all we’re doing is solving the problem of the XML Requests in a standardized way to make it easy for us to write modules and support software quickly.
We recognized the demand for the Converge integration when one of our clients needed it with Joomla. Then we talked to a few other people who not only needed it for Joomla and other applications, but were also willing to pay for a solution.
I agree with you on the login layer, though. OpenID would’ve been a much better idea than creating their own solution. It’s like they’re taking the Microsoft route of making proprietary everything with spotty interop. I think they only just recently put out a login module for OpenID.