It's a glorious day. You have the green light to start a new development project. You can almost feel your hands on the keyboard typing out glorious code and coming up with fresh frameworks that are devoid of all that legacy that has been keeping you down. Not so fast! There are a lot of critical things that have to be in place for a project to be successful. Here are some lessons I've learned from participating in the development of a number of projects.
Process
Pick a process. It's 2008 for crying out loud. Developing software without a process is just plain silly. I've been a big fan of the iterative approach including Scrum. Can you succeed with waterfall? Sure. Even a blind squirrel finds a nut every now and then. There's a reason why most people cringe when they hear the word "waterfall." Even the creator of the process sites it as a generally bad idea.
There are some different approaches, including Spiral Development and Evolutionary Prototyping. You can also go crazy and implement CMMI. I haven't used that particular model, but from what I hear it's pretty involved. If you haven't developed using a software process before, I probably wouldn't start there.
Requirements
Yup, you need them. There's no free lunch here. What is there to justify? This lesson has been learned over and over and over again. Without a clear list of items to complete, nothing good will come. Go down to a pretty low level of detail. Items such as "Options Dialog" are very high level. You should go down to the level of "The user shall be able to select a default font for the document. " The more work and detail you do at this point in the game makes the rest of the project go much, much faster.
Prototypes
Prototypes are critical in proving technologies and approaches. Within the source of a project I end up creating a number of prototypes. Some of these are little one off sandboxes that I toss. However, with most of these prototypes, there is some value in saving these as examples for other developers on the project, or as an easy way to capture the knowledge gained while sandboxing for later. I usually create a folder in source control just for prototypes.
Of course, if you're using the Evolutionary Prototype process, prototypes are bakes in. If not, prototype each new piece of technology before adding it to the main source tree. It's worth the time and will make sure that what you add to the main source tree is of decent quality.
Also, if you're team is learning a new language for this new project, plan on throwing away the first attempt at building the product. The only way to learn how to code is by doing it, but assume that the first iteration of building whatever widget you're working on will be crap. You'll learn lots, but you'll need to rebuild it. The good news is that when you do rebuild it, it will take a fraction of the time and the quality will be several orders of magnitudes better.
Source Control
There are many options available for Source Control. Just don't use Source Safe. If you're thinking about using Source Safe, just shoot yourself in the foot. Literally. It will be as painful as trying to use Source Safe and will save time (including the hospital visit). It's slow, unreliable, and horrible. The lack of critical features such as atomic commits, not losing data, etc is unacceptable. I've only used Source Safe and Team Foundation Server (TFS), so I don't have any advice to share for specific systems outside of those. As far as TFS goes, there are pros and cons which I go into here.
Continuous Integration
Do this from the beginning. Make it easy for everyone to build the software. This is a great opportunity for automation. Different platforms have their own tools, but I'm a big fan of Team Build for TFS 2008. It's pretty easy to set up and does most of what I want (although gating isn't going to come until TFS 2010 - aka Rosario)
Installer
If you application requires an installer, build one from the beginning. As soon as you're past the prototype stage, build the installer and maintain it throughout the dev process. Doing months of work then throwing it over the fence to the installer guy is a recipe for disaster. The amazing thing is that I've seen this done more often than not.
If you build this upfront, you'll be able to get feedback from the stakeholder much sooner in the process. The shorter this feedback loop is, the less likely you'll be to stray too far away from what he / she / they expect.
Short Feedback Cycle
Well, we just covered this in the installer bit, but it's worth mentioning on its own. Schedule work in short enough increments (2 to 4/5 weeks seems to be the sweet spot range) that you can get feedback. That breaks your work down into manageable bits and provides specific opportunities for the stakeholders to view the product (whether it's internal or external).
Internationalization
Build it in from the ground up. Yes. Do it now. I go into it in more detail here.
Draw Pictures.
Draw lots and lots of pictures. Keep them around. Whiteboards are the best for brainstorming (although it doesn't work well remotely). Use Visio - it's great. I've used the flowchart diagramming to do all sorts of things from program flow to installation scenarios.
Have a big overview picture. It's good stuff. Hang it on the wall. Keep it up to date. It will help a lot of conversations to have the big picture to point at to talk about where problems are.
Testing
Do it. Do it from the beginning. Have a tester develop a test plan from the requirements. Testing in flight will save sooooo much time. Throwing a product over the wall to testing after months of coding is such a horrible idea it's staggering to know that there are still teams doing this. If you want to get your product to market as fast as possible, this facet of the development process has the greatest impact on delivery time (not to mention product quality which ultimately effects support costs).
Unit Tests
Yes do them. Write your unit tests before you implement your code. Having repeatable tests that you can run at the push of a button is magical. If you can hook up those unit tests to an automatic build process, that's even better.
Code Reviews
Code reviews are a stellar bang-for-the-buck proposition. It is by far the cheapest way to reduce errors and ensure that the teams coding standards are followed. This is also a good way to make sure that individual members of the team aren't reinventing the wheel. I don't know how many times I've looked at someone's code on the team and said something like "oh hey, we already have something that does that. Use it instead."
Code Reviews should start from the very beginning of the project. Most likely, the code reviews will be the longest in the beginning of the project while the team is deciding on best practices. As the project continues, the reviews should be done just as often, but they probably won't take nearly as long (if the project is going well) because the team should be in a groove and not drawing outside of the lines as much.
Conclusion
There are a bunch of other things that you can do, but this is a good punch list of things that should be set up from the beginning of the project.
Posts
No comments:
Post a Comment