When considering the building of any software project, there is an array of challenges that should be taken into consideration to build a stable, scalable, fast, cloud-based, agile, and robust program.
Wait. What? None of that makes sense and I am pretty sure those are just buzzwords you picked up off some tech blog.
The reality is that, when creating a software project, there often is not a defined roadmap to the desired end. As noted within Three Flaws in Software Design, those are the flaws of writing code that is not for the intended purpose, writing rigid code that cannot be changed easily, and being too generic when writing that code. All of these pitfalls are further complicated by the fact that they often do not operate in binaries. It is often obscure if you are writing code that is too generic or adding unnecessary functionality. In the Dickinson Senior Seminar class discussion, we identified points to keep in mind to avoid these common pitfalls and questions to consider to avoid them.
- Write code that is flexible, not floppy - while not the most appealing to say, the concept of flexibility implies that it can take any form while floppy can only assume a form.
- Would this be able to change in the future? Will it be changed in the future?
- Plan but not too much - the planning step can be a valuable tool, but it can go awry. When planning, it is important to maintain a level of introspection and ask if this particular addition is too confining or limited in scope.
- Have I made an assumption for my ease? Should I consider alternatives?
- Don’t use a sledgehammer to crack a nut - whether it be writing the requirements or the code, consider if how you are writing is too complex for the task.
- Have you put too much work into one part? Is this approach unnecessary?
With these in mind, a software architect or developer will be on the right track to constructing a quality program. However, there is one more requirement: introspection. All of these points are for not if the person employing them is not prepared to consider they are wrong and it could be better - like git commits ask them early and often. Finally, much like the agile software approach, the final end cannot be fully anticipated at one point - rather it is an iterative process and these tips should be considered like that as well.