It’s hard to believe that it’s been a year since my Software lessons learned in 2010 post but it’s time again to reflect on lessons learned in software development in 2011.
Build on what you already know
I know this sounds obvious but wisdom accumulates over time and learning new things should not come at the expense of forgetting what you already know. Keep good lessons around and keep building on them to get better at what you do.
Don’t get attached
2011 has definitely been an interesting and challenging year with Adobe’s announcement on Flash mobile, Flex/BlazeDS going to Apache and re-orgs. In the re-org, I got assigned to a new group with a new technology stack, so it’s been quite a learning experience and adjustment for me towards the end of the year. Announcements about Flash mobile and Flex definitely made a lot of people think about their choice of technology in their organizations/projects including myself.
One big lesson I learned is to never get attached to a particular technology or group. Technologies come and go and even though one might be better in something than others, no technology is better in everything, so it’s not wise to invest a lot of time in one technology at the expense of ignoring the rest because when the day comes for that technology to become obsolete (and it will happen), you don’t want to feel abandoned or lost. Similarly, you might be working on the most interesting project ever with the smartest people around but don’t let the daily grind fool you into thinking that you’ll do this forever. It’s always wise to think and plan for the next step in your career.
Treat tests as part of the product
Most of the times, “product” is thought to be what gets shipped to the customer but I think this is a mistake in software craftsmanship. What gets shipped to the customer is a small portion of what actually is needed to build something shippable. Without unit tests, integration tests, performance tests, documentation, build scripts, etc. it’s impossible to ship anything decent. By not treating these as part of the product, we often let them be at a lower standard than the actual product and that’s a mistake because tests eventually start rotting and that makes the actual product harder and harder to change and maintain. I suggest that we give tests the same amount of attention, dedication and time by considering them as part of the product and you’ll be surprised if you do.
Just do it
I wanted to work on a side project and I spent a lot of time in 2011 to read on different technology blogs about different technology stacks, different RIA frameworks, different servers, different mobile development platforms etc. in order to find the right fit for my project. In the end, I learned a lot but I didn’t have anything tangible until late in the year when I actually started working on the project. Reading on things is definitely useful but it’s not as rewarding as actually building something. After I started to actually build my project, I realized that I’m learning more and I actually felt like I was doing something more tangible and useful, I was solving a real problem rather than reading up. So, my plan for 2012 is to read less, do more, and get more side projects finished because in the end, shipping quality software that solves something useful in some way is what matters.
Happy and prosperous 2012!