Monday 13 October 2008

Reviewing your software project - 4 questions to ask

[caption id="" align="alignleft" width="300" caption="Photo by wonderferret"]Photo by wonderferret[/caption]

You've now done everything you need to do and (hopefully) your project is a success.  Well done!  There is one more useful thing you can now do, which is to review how the project went.

This isn't so much to help with the current project, although it's no bad thing to step back and have a think about it one more time.  This is to help your with your next project.  You want to identify the things you did well (so you can replicate them) and the things you did not-so-well (so you can improve on them).  A big part of any software project is about learning how to do things well; the same is true of the process of building better software.

To this end, there are several questions you can ask yourself.

Did you meet your objectives?
Perhaps the most basic question you can ask about your project.  In other words, does your software do what it's supposed to do?  This should be the most fundamental consideration in your project, because, by definition, if the answer here is "no", then your project has failed.  However, there are lots of details and minutiae to attend to in any software project and lots of different thing to be considered (planning, coding, testing, roll-out etc) and so it's quite possible to lose track of the objectives if you're not careful.

You may find it valuable to look at each objective in turn.  How well did you meet it?  Are you satisfied with how it's implemented?   Is there anything you'd change, with the benefit of hindsight? 

What did you learn?
A great way to make your next project even better is to learn from your experience with this one.  So take some time to consider what you've learned during the course of this project.  This can be about the project itself, for example how to write certain types of code or solve certain problems.  Perhaps you've learned a lot about how to handle collaborators or the extra requirements for releasing code publicly.  It can even be about your own style of working and how you get the best out of yourself, for example, maybe you write code best in the morning and find the afternoons better spent covering other aspects of the project.

What would you do differently next time?
It's tough to do things perfectly.  Luckily, our aim has always been "only" to fulfill our objectives, so there may have been things that we did "well enough" and if the project has been successful, that's fine.  But maybe with hindsight you can see that there are some things you could have done better, if you'd had the experience then that you have now.

This is never something to worry about.  If you never spot anything that you'd do differently, it means you're not learning anything new.   Given that you did a good job on your current project, we think you should take pride in that and also be pleased that you've found some ways that you'll do even better on the next one.  We'd even go so far as to suggest that you pursue this theme actively.  Sometimes you'll be aware of an aspect of the project that was tough going or didn't work very well.  If it's not obvious to you how to improve this next time, maybe a bit of background research will help.  Search the Web.  Read a book.  It's surprisingly rare that you'll encounter a problem no-one has ever had before, so there may well be helpful advice out there that you can use.  You just need to look.

What would you do the same next time?
Of course, some things on the project you will have done well.  We think these are worth noting as well, both to give yourself a quick pat on the back, but also so that you're more likely to remember to do them again on the next project.  The human brain remember things more when they're reinforced, and it would be a shame to accidentally forget any of the good things you've spent time learning.


In conclusion...
Take a look back at what you've done and take stock of how your project has gone.  Remember what has gone well (and how), and try to learn from what hasn't gone so well.  Consider how you might improve next time.  We think that a good aim is to do a good job on this project and a better job on the next one.

No comments:

Post a Comment