Software lessons learned in 2011

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 worked on a number of diverse client and server side features in 2011 and I was pleased to see that lessons I outlined in 2010 were very useful in keeping me focused and guiding me in the right direction throughout the year. For example, I was tasked with implementing a JavaScript/HTML5 client library for Data Services but the problem was that I didn’t really know JavaScript all that well. I tackled that by allocating enough time for research and prototype and in the end, we ended up with a great performing JavaScript library using Google Closure. Another example is specs. I made sure the specs of features I worked on were up to date all the time and in the end, I was pleased to see our documentation and QA teams had almost no questions for me about the features because everything was outlined in detail in the specs.

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.

One example is my Java client SDK. In 2011, I wrote a Java client SDK but this time instead of writing a few unit tests and handing it over to QA, I wrote a fully automated unit test suite that tested every single functionality of the SDK. It took time and effort to cover everything and make sure it runs fast and consistently but in the end, it paid off big time. Shortly after Java client SDK, we decided to work on an Android client SDK, then JavaScript/HTML5 client SDK, then Objective-C client SDK and we simply ported these tests to respective languages. Throughout the process, we ran into issues and it was extremely useful to have a fully automated, fast testing readily available for the whole team, developers and QA. If something needs to change in any of the clients now, we make the change with no fear because we know that there are solid unit tests behind us to make sure everything still works. Investing in testing pays off in ways that you can’t even anticipate so why not treat them as part of the product?

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!


2 thoughts on “Software lessons learned in 2011

  1. Letting go is a huge problem for many people. It is especially hard when you’ve build a significant piece of software for the technology. Holding on to past projects will inevitably hurt your career as you will always be distracted by past thoughts and ultimately depressed that the tech is gone.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s