A week or two ago, a couple engineers and I were discussing software engineering topics and the following question came up: “Would you start a software development project without requirements”? As you might expect, this is a loaded question that has no single correct answer.
What follows are my thoughts on how to put the question and answers in perspective.
I would not (note that I did not use the word “never”) start a software development project without requirements. The reasoning behind is quite simple. You cannot (or perhaps the word is “should”) embark on a trip (note I did not use the word “journey”) if you do not know where you are and where you need to go. As an example, let’s assume you are interested in traveling to Chicago, Illinois to do some shopping and visit some attractions. You pull out your smart phone and ask Google to get directions to Chicago. Depending on your settings, it may ask you to specify your current location or assume it by default. In my case, I am in the Twin Cities of Minneapolis and St. Paul. A second or so after issuing the request, Google maps displays three possible routes. Some are faster than others; some are more scenic (and slower) than others. You then decide which one to use and you are ready to start your trip.
The same holds true for a software development project. You need to know what you are developing. The key is in the level of detail. The days of writing a Victorian Novel document for requirements are gone. I have been architecting, designing and developing software for internal and commercial use during most of my technical career. I am fully aware that at the start of a project, the client does not know exactly what he / she wants the software to do. Because of that fact, it is pretty much a waste of time to spend several weeks or months describing in detail what the software will do and putting together Gantt charts.
Experience and knowledge has taught me to start with a simple document with a few diagrams that can be used as a foundation to describe what the development team is aiming for. For example, if a group is developing a vehicle, and the client is thinking of a fancy and powerful sports car, the team would miserably fail if they deliver a powerful truck. On the other hand, the client it her/his might initially might be interested in a sports utility vehicle (SUV), but during the development process, the market changes and decides that a roadster (car with two seats) is what he/she really wants. Experienced developers know and understand the development process so they architect, design and implement the software keeping in mind that the only thing one can count is on change. There are several books that describe this fact in detail.
At this point you might think that the final answer to the question posed at the start of this blog entry is a definitely NO. Not so fast. Gathering initial requirements should take no more than a couple weeks. So, if there is a push by the client (and their accountants) one could hold on for a couple weeks and allow additional two weeks at the end of the project for polishing the end product.
In some cases, the team is already in place. This tends to happen in larger organizations. Perhaps the team finished a previous project, and now they are ready to start the next one. Would you let them go on holiday for a couple weeks while requirements are being collected or just start the project? My answer would be to start the project. The reason for this is that the most important item in a software development project is the team, not the generated documentation, or the tools used. The first couple weeks may be used to get ready and learn or polish on techniques and tools that could be later used in the project. The idea that a good team is a group of independent developers each of which is assigned a single task is a thing of the past. It is true that some projects require some special knowledge on some components. The idea is to spread such knowledge among most (if not all) team members. That needs to be done hands on. The best way is to split the team and have developers working in pairs or in very specific tasks in which the person with the most knowledge rotates or serves as a mentor for other with less experience. In reality, the person with most experience and know how on a specific task will be in the opposite end in other assignments.
Working in such fashion builds the team bonding and elevates the technical expertise of the team as a whole. If you understand this then the answer to the questions would be YES.
You can also spend the first couple weeks while gathering requirements getting to know in more depth the team members and the domain expert. The domain expert is the client who should always be available to directly answer questions regarding the required features (old and new) and to test the software that should be delivered once a week if possible. Today there are several tools that allow teams to follow Continuous Integration / Continuous Deployment practices. With such tools the software under development is constantly changing and available for clients to use and provide feedback (bugs, new features or modifications to existing ones).
In my experience with a software development methodology I worked on long time ago called Cyclic Development Process (CDP for short) projects need simple and changing requirements. Projects should last between 9 to 12 months. All features should start with failing unit tests. As the teams develop the actual software, the tests will pass. In many cases new tests or modifications to existing one may be required. New releases should be always targeted once a week. The major releases should follow the analogy of working from a skeleton, then on the organs and finally on the muscles and skin keeping in mind that most changes will occur during the start and first release. During the development of the second and third releases fewer changes will occur.
As an example, I architected, designed and for the most part developed a distributed storage server. The actual base code is over 1.5 M LOC (Lines of Code). I always start with a simple diagram (typically using Visio) that makes me refine what I am thinking before I start coding. The next step is to generate the unit tests for the feature. As the feature is being developed the unit tests and the target software evolve. When done, it seems that in most cases (never say all) the software works as expected and is reliable.
Not all developers have experience and have been educated on software engineering practices. I tend to read a book or two a year on software engineering. I have read books that are pro agile development and some that are not. Software developer practitioners at all levels (architects, designers, coders, senior and novice) should periodically question methods and practices. Seems to me that reading books is a must given that about 42% of college graduates never read a book after graduation and become part of the workforce. This statistic refers to electronic and paper books. Senior level software development practitioners should promote learning in their respective teams.
At this time I am reading a couple books. One is geared at refreshing and learning (it happens more often than expected) algorithms. The other is to polish on agile techniques and OOD (Object Oriented Design) patterns. I will include in this blog my observation of such books when I am done reading them.
If you have comments or questions regarding this or any other post in this blog please do not hesitate and send me a message. I will address it in confidence unless you explicitly state it in your email.
Follow me on Twitter: @john_canessa