Enterprise Integration Zone is brought to you in partnership with:

After teaching math (and a little computer science) for 14 years, Brian changed careers in 2006 with the idea that getting out of his comfort zone would be good. So now he works as a writer and programmer at Microsoft who specializes in PHP and Windows Azure. Brian is a DZone MVB and is not an employee of DZone and has posted 82 posts at DZone. You can read more from them at their website. View Full User Profile

DZone Top Article of 2011: 3 Components of a Successful Project

01.13.2012
| 17765 views |
  • submit to reddit

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:

  1. 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.)
  2. 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.
  3. 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

References
Published at DZone with permission of Brian Swan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Stacey Laurence replied on Wed, 2011/03/16 - 1:58pm

Hi Brian, Thanks for a well-put and highly interesting post. The 3 requirements you discuss above are supposedly basic and obvious, but actually it's in real-life developement situations where we tend to forget just how crucial they really are. When a whole planning session is used up for tedious, high-level debates it really is paralyzing. At the end of the meeting, when you find yourself out of time (and you have to actually deliver your plan today), the practical decisions are forced to either be made on one foot, or called by the manager, and the whole debate has proved meaningless. My two cents are that such methodologies like Agile or Scrum really help shorten the planning process and dive in to the 'doing' much quicker, because they allow time for dynamic fixes while you go. For example, the simplest idea of a stand-up meeting in the morning is great for shortening and focusing frequent, day-to-day decisions.

Kookee Gacho replied on Sun, 2012/06/10 - 12:04am

Stratospheerius is a musical group of the Jam Band and Funk genres, in a style they call "psychojazz trip funk". The New York-based group has opened for Tim Reynolds, The Slip, Ekoostik Hookah, and John Scofield among others. - Marla Ahlgrimm

Paul Russel replied on Sun, 2012/06/10 - 8:07am

whenever a client tells me their idea is simple, i immediately believe it is likely not.  in my experience, they say so because they want their project done quickly and/or cheaply.  it is not the client's job to decide whether a project is simple or cheap.  all they can do is give a budget and a timeline, both of which help to define the project.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.