There are much-talked about, and yet often-neglected facets of software engineering. These are the ones left untold by the legends of rock-star developers cranking out famous pieces of software single-handedly on little or no budget (think Facebook). Successful software products rarely bloom as the result of gathering a few genius coders and letting them loose on an idea. In order to be a success, a product needs so much more than a piece of code that works. It needs to be understandable, maintainable, documented, and extensible. Most importantly, it needs to be funded, marketed, and sold.
It takes a team in order to accomplish all of these goals. The first challenge in building software as a team is building the team itself. Of the grand pool of engineers each has different skills, levels of experience, and personalities. Each will affect the overall culture differently, sometimes in ways not entirely in the control of managers and leaders. However, with the right team, a good choice and implementation of methodology can do a lot to help guide the culture in a positive direction.
A software development methodology
provides a framework for structuring, planning, and executing on a project. It helps teams organize and think about the when and how to work different parts of the product. One of the most important things gained from the methodology is a framework for communicating about the work.
The methodology will provide terms on which the team can align. Software is an abstract form of engineering, and though you can make analogies to say, building a house, it is ultimately more difficult to communicate the many concepts that go into it.
All of the success goals listed above have one requirement in common: documentation. A well-documented product will be much easier to understand, maintain, extend, fund, market, and sell. Good documentation also reduces the communication overhead incurred by each additional member of the team, and team communication is key. To learn more about communication overhead (and see what sparked my interest in this side of software engineering years ago) explore the canonical Mythical Man-Month
This is the first in a short series of blog posts in which I will be expressing a few of my thoughts and feelings on the human aspects of software engineering. I will be diving deeper into team building, methodology, communication, and documentation.