I’ve been “working” on a web app for sometime now and will use it as my “calling card” moving forward. It’s just something small and effective that I need to create to ship something into the world, to break the ice, and to create a platform to build off of.
The problem is that I plan too much, too often, and when I get stuck planning the application, I freeze and don’t do anything. But, it doesn’t have to be that way for technologists and software developers.
When I was working for a large insurance company we had some intense project planning going on. Timelines, small project packets (200 pages isn’t small though), meetings, meetings, and more meetings. It felt like overkill, but, in reality was probably an important thing to do for the complexity and depth of what was going on with different pieces of software, not to mention we had to make sure that regulatory and certain legalities were taken care of. Some of these systems were 20/30 years old and we were integrating new stuff with them which added another portion of complexity.
This type of in depth planning is mostly needed for large systems (although, some of the meetings were a complete waste of time). But, even those these plans that are in a perfect little Gant charts, created with picture perfect white board sessions, and detailed in small project packets with code and comments aren’t perfect and sometimes completely fail.
With smaller systems and apps we have the choice to not go into as much detail when we plan. We can get away with skipping complete plans and timelines and concentrate on smaller, more concise plans that actually mean something. Here are two awesome resources for planning software:
- Painless Function Specifications Series from Joel on Software
If you want to do a little more in depth planning, this is the way to do it.
- Getting Real by 37signals
If you want a “no-BS” approach to making quality software without the overhead of planning too much, this is the way to do it.
Here’s the hit
If you are planning large or small systems you can’t do it perfectly (even with the awesome resources above). You can get close to creating accurate plans, but it’s never perfect. So, instead of spending the time to create a plan that is “iron-clad”, spend less time making a passable plan and then start creating. When you hit a brick-wall with your plan or things don’t match up with your plan then change your plan.
What tends to happen, at least with this technologist, is that I plan some software (mockups, requirements, small functional spec, etc.) and when my actions start to go outside of the plans, I start to think that my plans are “wrong” and then scrap them. That’s not how it should work. We have to remember as technologists and developers that plans will change, especially for small or medium size systems and even more so when you don’t have any sort of hard requirements (like legal or regulatory).
So, rather than plan for perfection and think that you have failed when plans change, plan for change and understand that your systems will never be perfect even after the system has shipped.