Recent Happenings
I am definitely in a funk of some sort.
I’ve just been completely out of it ever since I pulled a 110+ hour week at the beginning of November working towards the release of the project I’m working on: FCG’s FirstPoint.
Now that we’re nearing the end of the year, we’re getting ready to prepare a release.
I think what I’ve learned from this process is, surprisingly, the importance of process in software development. That’s something I thought I’d never hear myself say (or see myself type). Having gotten my start during the tail end of the startup era in 2000, I’ve been used to small teams with light processes to promote speed and efficiency. But I think often times, people who don’t have experience putting together large projects are all too willing to sacrifice “doing it right” for “doing it fast”.
I’ve always been an advocate, but this go round, I think I might have been too soft and let off of it too soon.
One has to insist on some level of process that defines an overall workflow from conceptualization to realization, even more so for remote teams. Certainly, these processes and workflows should not be set in stone, but they must be considered and they must be documented for the better of the team and progress.
Cooking a meal for 2 is easy enough; most recipes are written this way and most cookware is designed for preparing such meals. But how about preparing a meal for 200? All of a sudden, the scale of it all changes dramatically. One needs larger infrastructure to support the ingredients, larger cookware, larger utensils, more manpower, and most importantly, there must be a process and a “glue” to hold all of these components (cooks, prep stations, servers, dishwashers, etc.) together now and ensure that the components work in unison.
Without process, planning, and infrastructure to support it, such an undertaking will surely be painful and the dishes will likely be served slightly late and a bit cold.
In writing software, the boundary between cooking for 2 and cooking for 200 is a very fine line. It’s not so much as how many concurrent users the software will support (although that does increase complexity), but how many features must be included in the software package. When preparing a dinner for 4, preparing a two course meal will be significantly easier than preparing a 7 course meal simply due to the lesser number of ingredients to prep, store, and cook.
With software engineering, all too often, it is simply too easy to go from preparing a 3 course meal to a 7 course meal if scope and feature creep isn’t controlled. I think process can help this by ensuring that the introduction of new features isn’t simply “hey, I need this new feature, can you add it?” but more involved and includes a thorough evaluation of how the feature fits with the existing feature set, whether it is a “must have” feature (of course the boss always says yes :), and planning to consider whether it is part of a larger featureset that can be slated for a later release.
Process defines milestones and encourages visibility to the timeline of the project. It makes the future more tangible. If you know you have milestone 1 in three weeks and milestone 2 in 5 weeks, it makes it easy to schedule a task estimated at 4 weeks of work for milestone 2 instead of trying to shove everything into one giant release. Process defines the workflow for introducing new features in a controlled manner such that features are not introduced in one module that breaks another module since, with the right process, those involved will have long since had a chance to review a rough design specs and will know ahead of time, the changes needed to adjust. Process ensures that code that is commited is well written and written to a common standard. This is done through mandatory peer reviews and knowledge exchanges on regular schedules.
But in any case, ’tis a lesson learned.
