Three Components of a Successful Project
Earlier this month I attended the monthly meeting of the Seattle PHP Meetup Group. In ways I didn’t expect, it was a very interesting meeting. The content itself was interesting enough (we were talking about database design), but what I found even more interesting was how the meeting dynamics provided a good reminder of what goes into a successful software project. What I observed was nothing new – what I have to say will all be familiar to anyone who has run successful software projects – but my observations served as reminders of some of the key components of a successful project.
First, a little background…
Back in December, one of the meeting organizers, David Malouf, suggested a group-wide project that would drive our meetings for the next several months. He outlined a very simple data-driven application that we, as a group, would build. The details of the application aren’t important here, but the fact that his idea was simple is important. The members in our group have widely varied backgrounds – everything from complete hobbiests/newbies to professional, very experienced developers. Building a simple application would allow newbies to have insight into the complete application development process (without getting overwhelmed with finer points) while allowing those with experience to share best practices about the various stages of the process.
I have to say that I think this idea of a group-project is an excellent idea. So far, it has given the group a very real backdrop against which to have conversations about OOP vs. procedural programming, model-driven development, UML, class design, and tools that can assist with all of these. Most recently, we talked about database design, designing for the future (i.e. scaling), database abstraction, and (again) tools that can be useful. Newbies have had a chance to see the beginning stages of building an application and how the many decisions in such an endeavor are weighed. Those with experience have been able to share and debate ideas while gaining even more experience in leading and presenting to a group. The path ahead contains lessons in actually writing code, maintaining a code repository, collaboration, etc. The list goes on. This experiment is young, but I would highly recommend it to any group as an excellent learning experience.
And now for the the reminders about what it takes for a project to be successful…
One of the problems our group ran into in our last meeting was this: we couldn’t settle on a database design because we ran into analysis paralysis. We talked about simplicity vs. scalability. We talked about performance and maintainability. We talked about normal forms. We drew sketches, erased them, drew more sketches, and erased them. And, at the end of a 2+ hour meeting, we had no database design (for a very simple application). From a certain point of view, this was great – this is what Meetups are all about, right? We had learned a lot about database design, even if we hadn’t settled on one. Well, I would agree if we weren’t actually trying to build something. We could spend the next year’s worth of meetings debating the design for this database and never get to the application (which, IMHO, is a goal that stands to provide a richer learning experience). This is a potential problem that any software project faces, and certain things need to be in place to make sure that you, the development team, are forced to make the tough decisions that will ultimately lead to a successful project. Here are some of the components of a successful project that I was reminded of:
- Make sure your client’s requirements are clear. Part of what bogged us down was that the requirements of the application weren’t clear. In retrospect, this is completely understandable. David, our organizer, conceived the project largely as just that, a project. When we started throwing around database design options, we came back to him with lots of questions – questions he understandably hadn’t thought through. One thing David is doing between our last meeting and our next is figuring out exactly what the requirements are. He’s actually playing the role of a client. (For a more in-depth look at what it means to be a good client, read Cal Evans’ blog series: Six ways to be a better client for your developer.)
- Have a clear timeline. Even with clear requirements, I think we could spend the rest of this year’s meetings debating database design. And, if not database design, then some other aspect of the project. But, with a clear “ship date”, we’ll be forced to make tough decisions – we wont’ have the luxury of exploring every option. At the end of the day, as with real projects, we’ll have to deliver something.
- Have a project manager capable of making tough decisions. Healthy debate and exploring options is fundamentally important to a project’s success, but without someone designated to make sure we are honoring the client’s requirements and that we are on schedule, the risk of analysis paralysis is still great. There will be times when someone has to say, “Thanks for all the input. This is what we’re going to do...”
These are by no means all the elements that go into a successful project. They are, however, elements that we will have to consider in our group project. And, I think including these elements in this educational endeavor will bring new insights into what it takes to build an application.
What do you think? Comments on any/all of the above are welcome and appreciated.
Thanks.
-Brian