How To Finish A Big Software Project And Be The Hero
We've all been there! The huge beast software project that just won't end/die. In fact Microsoft is constantly getting themselves into this trouble. Vista, SQL Server, XP, all became these huge projects, that in the end, had to have massive features cut, and new leaders appointed to save the day and ship products! At the end of the day, if you are constantly building and building, and never shipping, you’re sunk! How do you get a big software project out of the water and become the software development hero? I'll tell you how...
First, a little history to how the big nasty project starts! A huge software development project is dreamed up to solve some complex problem. Great, that's what software is all about! But things start going bad right on day one! How?Well, the managers and executives decide that they are going to plan every detail of the software project to the most minute detail. They then assign a project manager to manage all the developers and let them start building each piece independently one-by-one. A few weeks before shipping, the project managers try and combine everything, and all is well right? Wrong... Disaster! The project is delayed! Days pass, weeks, months, years! What the *beep* just happened here! What to do?
It's Like Building A Building
Have you ever seen the construction of a building? Does everyone go into their own little silos and build their own thing? No! How is a skyscraper built? First lay the foundation, then put in floors, with the elevator shafts, then build floor after floor, then the interior, etc. Could you imagine what would happen if every piece was built in a different site, and then later everything was dropped off at the construction site to be assembled? Even if you had the best plan to assemble everything together, you would have problems! Things wouldn't fit and would have to be re-done, architects would change their minds, pieces would be missing, and the building would look like a bunch of match sticks!
Be The Software Hero, Finish That Project
Does your software project feel like a disaster waiting to happen? Is it already a disaster? Are you ready to get the software project on track? Here we go...
- Source Control
Do you have a source control system? If you don't, that is a major problem! Get one ASAP. Without source control you might as well go play Russian roulette. You can't rollback changes, you have no backups of your source code, you have no history, and it will be nearly impossible to set up proper continuous integration! - Continuous Integration
Do you have a continuous integration server setup? You know how every time you check in code, and you get the build master to build your code, everything blows up? That's because he is only making builds when told, and this is probably not often, let alone every time someone checks in any code. Continuous Integration will automatically build your project, and give you the results of the build. You can even add Unit Tests, Coding Standards Tests, etc. But let’s keep it simple to get you on track! - Bug Tracking System
Without a bug tracking system you have no way of knowing where the quality of your software stands easily. At any time you should be able to see which features are being built, tested, approved, troublesome, etc. If you are relying on excel lists or written notes, invest the money in a bug tracking system as soon as possible! - Patching System
I'm not going to get into installer issues here, but you need a patching system. You do not want to deploy installs upon installs to your testers. - Disable Untested Features
Turn off every feature in your application that has not been completely bug tested and approved by your users. If your project is in trouble, you have hundreds of features implemented at 80%, and you probably think they are at 90% - 95%, but they aren't. - List Major Features
Make a list of all the major features that are involved in the software project. Start at a very high level. This is the key step to start turning around the project. You are going to pick your battles here, small, winnable battles, instead of fighting a never ending battle with thousands of features. - List Top 20% of Major Features
Ok so you have a list of all the major features, now take 20% of the high level features and make another list of those. These are the features that must be implemented for a great pre-release version of your software. - Detail Out Top 20%
For the 20% List, make another detailed list of every feature that needs to be implemented in order for these 20% items to be completed. Rank these features by importance. I like to choose the most complex ones first, and end with the easier ones. This makes it easier to know if you are on track, as finishing easy features first, won’t really give you any indication as to how much longer you are going to take. - Plan The Week
Carefully figure out which of these features you can complete in the next week. Assign out features to developers on the team. When you assign them, try and keep similar features together. Make sure everyone is checking in code regularly. When they check in, if they break the build, they must fix their build immediately! - Create Branch
Using the source control system you chose, create a branch. Your goal here is to create a branch, label it as the testing version, and then release a patch in the next step. Next you start working on the items for the next week, while your testers test. - Build Release for Testers
Get your Build Master into high gear; have him build a patch for your internal quality assurance team. - Testers Take Flight
Hopefully you have a Quality Assurance Team, if you don't start with at least one person and get them setup with the Bug Tracking System. Get them to get the patch as soon as it’s available, and get at the testing! By the way, if you can include customers or end users in your quality assurance team, do it! As soon as your testers find any bugs, issues with implementation of features, etc. make sure they report them to the developers! If you have a good bug tracking system, the system should automatically email the developers when your testers give feedback or change the status of bugs. - Software Developers Work on Trunk
While your testers test, your developers keep working on next week's items. As bugs come up, they go back to the branch, resolve the issues, and go back to Trunk Development. - Approve Patch
Your testers have completed the testing? Everything looks good? AWESOME! You have just completed your first set of features that are now ready to be installed! Technically, if you have followed the procedures outlined above, a customer or client tester should be able to install this software, get the patch, and use it! - Continue Steps 9 to 14
Continue your efforts over and over until you get the 20% done, hopefully this is not as far away as you think!
Your goal is to focus on small features, get them done, and send out a release for testers. This is a huge shift from trying to complete 100% of your bug ridden huge project.
Your team will be extremely motivated to be releasing workable software every week! They will actually speed up, and the whole project will start gaining unbelievable momentum!
When testers find bugs, your developers will fix them faster because the code they wrote is fresh in their minds! If features need to be tweaked and changed, it gets caught early, and changes are much more fluid!
Your business users will start seeing results! They will in turn give you more resources, better tools, and more respect! The shiny happy people will hold hands!
Is there a lot to do? It depends in how much of a mess your development lifecycle is. If you have nothing of the above setup, you are going to have a tough time, but if you focus and execute quickly, you should have no problem's setting up the ideal environment quickly.
Enjoy being the Software Development Hero!









Item #12 - hopefully your testers are involved much earlier in the process than testing the delivered code - and remember that you cant test quality into a program...
Joel does it in 12 steps not 15 ;)
http://www.joelonsoftware.com/articles/fog0000000043.html
Posted by: philk | August 15, 2007 at 03:12 AM
The problem with software projects and software in general is, that it is not visible. If you build a house without a wall, everybody see it. If you are digging a hole, everybody sees you are working on grounds. But if you are working on a framework that will save you a lot of time later, it is not visible and it is just a "vaste of time". So, one of the most important factors is trust of the stakeholders. Otherwise you are lost, no matter what methodology you use.
Posted by: Roman Mackovcak | August 15, 2007 at 06:45 AM
Joel has some good steps I love Joel on Software, however his is more of "tests" and questions to ask yourself.
Also we have QA involved from day one. This plan should do that as well. In this plan, QA is involved from the beginning, and the QA testers are testing the software constantly. It's a completely iterative process, with software that works with 0 bugs weekly. Life is goodness :)
Posted by: Miguel Carrasco | August 15, 2007 at 07:18 AM
I actually appreciate this list over Joel's list because it actually takes into account that clients and stakeholders need to manage the features. Having a CI server will be for not if feature creep occurs in the last month of development.
Roman - I would actually disagree with your statement. If you are building each feature from top to bottom per feature (in an agile manner), you should have no problems with transparency of progress. It is only when we stubbornly build exclusively bottom up that progress is transparent.
Posted by: Max Pool | August 15, 2007 at 08:59 AM
Thanks for the great comments Max! Good luck with your development projects! To be compared in the same sentence with Joel Spolsky is definitely an honour. His writings have been a great motivation in my development life.
Miguel Carrasco
Posted by: Miguel Carrasco | August 15, 2007 at 01:15 PM
Hi, Thanks very much for this article. I was wondering if anyone had the same steps for relating to a complex web app? Something with a fixed feature list, budget and timeframe?
Would really appreciate any comments anyone has?
Thanks again
Chris B
Posted by: Chris B | December 12, 2007 at 05:26 PM
Great guidence! Based on my experience, the problem is because the sw architect only provide papers and slides (and talk) like building architect. However, if sw architect himself capable to provide completely built demonstratable pre-release which consist of framework and top 20% major features, the rest will be much easier to control. Thank you.
Posted by: Deru Sudibyo | December 24, 2007 at 02:03 AM
Finding the right software licensing strategy...
I am a software developer at a small firm in the process of developing an effective licensing strategy that promotes viral adoption, but limits excessive piracy. Any thoughts on solutions or strategies in this area?
Posted by: Paul Harris | April 30, 2008 at 01:21 AM
Paul,
Paul,
Regarding a licensing strategy, consider third-party licensing technologies that allow the balance between copy protection and casual sharing to promote word-of-mouth marketing. Piracy is a huge problem worldwide for publishers and device-based software authentication is currently the best approach as it locks the user’s machine to the authorization to confirm identity.
Complement this with the ability to audit piracy on a global basis using technology from a company such Uniloc which pushes a product called SoftAnchor. Uniloc also allows you to use the piracy data, graphically defined by region (country, continent, etc.) and throttle the licensing parameters to adjust for areas of aggressive piracy. This also allows the loosening of licensing restrictions in areas of lower piracy to promote viral product marketing and greater sales.
There are a few good solutions with SoftAnchor that strike that balance between polite copy protection and viral awareness. It has global piracy auditing, license auditing and device-based authentication and is one of the solutions to put on the short list – we use it here. I would also recommend a solution that makes it possible to implement and maintain secure, embedded product activation in-house. You definitely want embedded seamless security that provides unlimited tripwires and validation checkpoints.
Hope that helps,
Gerry Dufficy
Posted by: Gerry Dufficy | April 30, 2008 at 04:35 PM