Successful Software Development
Software Development tries to mimic the real world in many ways. Unfortunately, with the good comes some bad. Specifically, I am referring to the many great “Software Holy Wars.” Geeks passionately take sides on such issues as using Data Sets vs. Objects, DTO vs. Domain Model, or Contract First vs. Code First Development. In many situations each side has merit and one must ask in which direction are the requirements leading us? For example, I don’t like to use Data Sets for Data Set sake. However, if I am building a Smart Client Application that must have disconnected capabilities using Typed Data Sets brings much power to the table. In this case Type Data Sets have several baked in features that make data persistence and state easy to track. So keep an open mind and look at development tasks on a case by case basis. On CSI Las Vegas they always say “… let the evidence guide you,” in our case as developers it is that requirements that should guide us.
The above statements are fine and dandy but I already imagine some critics picking away at my suggestion to follow the requirements because the requirements may not always be complete or clear. Here I suggest it is our jobs as developers to help flush out unclear requirements. Developers, raise questions about the code they are writing and help develop a solution. Developers also make suggestions to the stake holders. Once a decision is made it is our job to carry out those decisions.
So far I have proposed letting the requirements help resolve architecture design conflicts and to identify and help resolve missing requirements. Next, I would like discuss the importance of a positive team environment. So is this where I start advocating all the HR hyped retreats and team building exercises. If you think so then you don’t know me to well. Blah! I’ve worked in what I consider both positive and negative team environments and the difference comes down to a few simple points. They are as follows:
- Every one will eventually have a bad day, just remember to treat others with respect and follow the GOLDEN RULE.
- Assume everyone was hired for a reason and has something valuable to contribute. Great ideas come from all skill levels, genders, races, etc.
- Share your ideas.
- Sometimes you may be asked to prove your idea. This is an opportunity to shine. If you realize the idea is flawed you’ve learned something in process and thus still succeeded.
While nothing I’ve outlined is revolutionary or earth shattering, it is my best advice for successful software development based on my experiences in the work force.