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:
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.
Share this on Twitter