A typical project timeline
Starting a software project and turning it into a business is always a thrilling time. Everything seems to move along easily and at a good pace when suddenly the first issue pops up, a quick workaround and then you continue to move forward. Again, just as before another issue appears. It is an annoying issue but not related to the project at end. Maybe a dependency that has not triggered out a recompile. It takes half an hour to figure it out; recommendation is to execute "make clean && make" next time. It takes fifteen minutes to rebuild the project; we will live with it.
More issues on the project are now popping out at a rapid pace. It takes longer to bend the IT infrastructure into a state where an issue can be investigated and time is running out. Pressure is building up to show a prototype, something that works... anything. We have to justify the investment to keep cash flowing in. A few top engineers realize that part of the troubles today is exacerbated by an unreliable infrastructure to support the development team but they will stay quiet. Responsibilities are shared between developers excited to start something new and accountants excited to get quick return-on-investment. A few executives wander around the office as if the sky had fallen on their head. They start wondering whether “praying for a miracle” would be a viable strategy. Everyone wishes we had started a Quality Assurance feedback loop earlier.
Starting an innovative software project, turning it into a business, making profit out of version two is all but out of the ordinary. Heroic efforts are always necessary to achieve anything out of the ordinary. Nevertheless, as all heroes have gadgets to enhance their incredible innate abilities, developers will need a dose of magic to deliver amazing results. Some of that magic can be found inside fortylines development infrastructure. It is made up of thoughts, information and tools based on years of experience in software start-up engineering. Hopefully, you'll find them useful.
Software as a lifestyle
Building software systems, as any human activity that requires coordination of highly creative minds, is a very risky business. Ideas mature, stabilize and turn into processes. Quality control insures that, along the way, labor-intensive organizations or automated computer systems slowly replace risk associated with individual contributors.
New and innovative projects have always relied one hundred and ten percent on talented people and these have always been very independent and never shy of expressing a lifestyle out of the ordinary. Each talented person I have met had a specific lifestyle that makes him or her creative and productive. If what you need is a team of talented people to work on a project, the policies and infrastructure of your project have to be carved around that fact.
The Internet did not bring back the mini-computers era; the time of centralized computers and Teletype terminals is long gone. Today, each developer has his own machine that he carefully sets up to his own taste. Any policy that intents to keep engineers productive needs to account for a variety of local machines. Very many of the brightest engineers I know have switched to a laptop as their primary development systems. They also work in different time zones even when they are physically in the same city. To avoid severely impacting productivity, systems should address intermittent network connectivity and limited live communications.
Different people have different interests and expertise. Some days one is very careful and dedicated about writing a piece of source code and other days, the same one is following an idea, but is cutting corners along the way. It is individually very hard to differentiate a brilliant masterpiece from an uninspired realization. This is the root cause for most bugs and long reaching costly mistakes. Quality Control is far and foremost the art of mixing individual motivations and making all information available to each contributor. Design guidelines, code conventions, document templates, web-based source code browsers, and automated e-mail of commit messages are examples of tools to achieve that goal.
Quality Control also guarantees that a new release of a project is at least as useful as the previous one. Testing for regressions is critical to make users happy and developers involved. Unit tests, integration tests and metrics tracking are among the tools used to automatically raise early warnings.