Very Important Things to consider while writing programs in software development

Every day, a software project dies. Some die a slow, painful, expensive, death. Others die a quick, not painless, and relatively embarrassing death . As Software Engineers, we never want our own projects to die. As individual contributors the livelihood of our projects are often times outside the realm of our control. At the same time, there are many things that are within our control that can help the projects that we work on be a success.

This is a list of things to consider while writing programs in software development— habits that when practiced, will not guarantee success in a software project…but will greatly limit the possibility for failure.

Learn from your neighbor – It doesn’t matter if your neighbor is a Junior Programmer or the CTO – run your ideas past them and see what they think. If your neighbor has more expertise then you, then they may have some tried and true advice to get you past the roadblock you’ve been hitting in your code for the last hour. If they are less experienced, then challenging them with a complex problem and discussing it with them may help grow their expertise — something that will surely help your team in the long run.

Keep it simple – This is so easy to say, yet so hard to do. This is the one item that I have to constantly remind myself of when developing software — Software geeks often generate their own requirements without even realizing it (‘Example: Oh, I bet they would like it if they could do this this way OR that way!’). Antoine de Saint-Exupery said it best – “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away” – Ask yourself each day – ‘what can I remove from the software and still maintain the essence?’ – This alone will get you heads above the rest.

Your code must speak the same language as your client - I’ve been reading bits and pieces of the book Domain-Driven Design . The one main message I am taking away is that the language your code speaks and the language your customer speaks need to be one and the same. If your client keeps talking about how the ‘Policy’ can be sold by a ‘Salesperson’, then maybe you should name your classes ‘Policy’ and ‘Salesperson’, and name your method ‘sell’ not ‘widgetA’, ‘thingB’, and ‘update’ (OK – this is very over-simplified…but the point is that your code will ROT fast if you need to go through multiple layers of translation to understand the changing requirements…let your code be the voice of your customer!)

Water your brain – If you aren’t reading reference books to keep up to date, then you aren’t doing your job as a Rockstar Software Engineer. I don’t care how sweet your code is…if you can’t pick up a few books a year written by the software gods (even if it’s just for a quick refresher) – then you aren’t doing your team any favors. There’s plenty of great books out there to read (and plenty of crappy ones too — so be careful). Two books that I like to read at least once a year are: Smalltalk Best Practice Patterns and Design Patterns — yes I know, very old school, but there are timeless nuggets of information within each! Recent books I’ve read or are reading include the Domain-Driven Design mentioned above and another Kent Beck book, Implementation Patterns. I’m always looking for new books — what is in your library?

Test first - Sorry to break the news, but test-driven development is not a buzz word…it’s something you need to do. If nothing else, it will force you to Keep it Simple. If you write the tests first, you can define the criteria for success up front, therefore providing you with a finish line — when the tests pass, you’re done. Without a finish line, it is so easy to keep running….and running and running, until you have implemented what you think should be implemented…not what the customer needs

Introduce your code to your team - If you work in an environment where there is shared code ownership, this is incredibly important. When you are working on something that you know no one else on the team is familiar with, review the code with them when you make changes. This can accomplish several things at once. First, When you are on vacation without a cell phone, your team will know how to fix your wacky code – We’ve all been here… The last thing you want is to have a message from a co-worker on your hotel room phone in Mexico saying that all hell has broken loose! Secondly, the best brain to have on a software problem is the one that isn’t biased towards a solution. If you wrote the code, you are already biased — you think it is the best way to solve the problem, whether you like it or not. A fresh brain can point out the obvious ways to do it better — and that is a good thing for your team (even if it hurts your own ego a little bit).