Software lessons learned in 2010

As we’re wrapping up 2010, it’s hard to resist the urge to look back and reflect on things that I learned or reminded of in 2010, related to my job as a Computer Scientist at Adobe. Here they are in no particular order.

Prototype, prototype, prototype

Throughout the year, I worked on a range of smaller and bigger projects. Sometimes I had the time to do a good prototype of what I intended to build, and other times, not so much. One thing I realized is that the more work I put in prototyping upfront, the better the end result was. By end result, I don’t necessarily mean the code, but rather the whole software life-cycle. When the prototype was good, the specification of the feature was bullet-proof and detailed, the test plan was solid, the code was nicely designed and implemented. When there was no or little prototype, everything was less certain, more fluid. Especially in complex projects, there were always some aspects of the feature that I wasn’t too sure of at the beginning. I was either utilizing some new technology that I wasn’t totally familiar with, or I wasn’t too sure about how the new feature would fit in with the existing architecture. I could simply hand-wave and assume that things would work themselves out, but depending on assumptions in software development is never a good idea. Instead, I often tried to allocate  some time to experiment and prototype with the new feature before I started writing the spec. This allowed me to get a clearer picture of the problems I might run into, and also provided me more depth into my arguments as I wrote the spec. Prototyping also helped me to jump-start the implementation. So, one big lesson I learned this year is to insist on having time for prototyping, and to not let the release cycle crunch treat prototyping as a luxury. Instead, get yourself and people around you in the habit of making prototyping a necessary step in software development, and I can guarantee you that the end result will be much better.

Better estimates start with smaller estimates

In software development, estimating how long a certain task is going to take is everything because your estimate is going to affect a number of other estimates, and if you and a few other developers get their estimates wrong, you can easily jeopardize the whole project. Breaking down estimates into 2-3 days of work is something enforced by my manager and I have to admit, I wasn’t too enthusiastic about the idea until recently. This was partly because I see software development more of a creative process and I didn’t think it can be framed into 2-3 days of concrete work items. Throughout the year, I came to realize that even though programming is a creative process that ultimately carries some level of uncertainty,  it can be broken down into smaller units of work that can be easier to estimate. Once those small estimates are added up, you end up with your final estimate which can be quite accurate. Sure, estimates could shift a little, but in the end, if you know what you’re designing and implementing, you should be comfortable with expressing your project in 2-3 days of work items. If you can’t, then you need to go back and do more prototyping or research until you can. The more you can break down your estimates, the more accurate the overall estimate gets, and that’s better for everyone involved in your project.

Keep a log in addition to a TODO list

I always kept a TODO list in some shape or form before, but this year, I got more organized, and I not only kept a TODO list but I kept a log of things that I actually accomplished every day. I know this sounds tedious but it takes only 5 minutes to move your TODO list item into your accomplishments log in a given day, and it’s well worth the time for many reasons. The obvious reason is when it’s time to review your accomplishments with your manager at the end of the year, you have a long detailed list of items to go through; the log makes sure you get the credit you deserve. The less obvious but more important reason for me is that, a log is a good way of reflecting on the day. By getting into the habit of reflecting on your day, you make sure every new day is better than the one before, and you get to make incremental improvements in your work habits to get the most out your day. I definitely realized that by keeping a log, I improved my productivity quite a bit, because I had the extra motivation to make sure I had something worthwhile to write to my log at the end of the day.

Give life to specs

Most of us write specs at the beginning of the software life-cycle, once the spec is signed-off, we forget about it and focus on writing the code which is supposed to reflect the spec. But we all know that no implementation will implement the spec 100% unless you write the spec after the code is done. Once the coding is done, you sometimes remember to go back and update the spec, but often you do not, because spec doesn’t really matter much after code complete, right? WRONG. There have been so many times I had to refer to the spec well after code complete, sometimes after a detailed customer question, sometimes to refer internal folks so they can understand the feature better. I think it’s good to get into the habit of updating your spec as you implement. I’m not talking about changing the spec as you code, but rather adding extra details to the spec as you get a clearer picture of the implementation. This way, your spec will be much more detailed and accurate once code is complete, and you and your team will benefit from this.

Engage with your community

I had the privilege to attend two Adobe internal conferences, and also Adobe MAX this year where I got to interact with internal and external customers and groups. The more I attend to these conferences, the more I realize how important it is to get out and interact with your community. You not only get a lot of useful feedback on your product in these conferences, but you also get to make connections which makes your job more fun.

Staying focused is a learned skill

Multi-tasking is a myth, especially for software developers. You cannot design a complex algorithm while reading email, and answering questions on the phone. Instead, you should focus on doing one thing right at a time, instead of doing multiple things half-right at the same time. I constantly challenged myself to stay focused on my task this year, and I have to admit, it’s hard. However, I’m getting better, and the span of time I’m staying focused is getting longer and longer which makes me believe that staying focused is a learned skill.

Be scared

When I look back in 2010, the features that I thought were piece of cake were indeed piece of cake, and I don’t remember much about them. The features where I was nervous in the beginning, or where I ran into a problem halfway along and had no clue what to do, I remember them vividly. Same goes with customers. Some customers were very easy to deal with, some customers took a lot of time, and effort. In the end, all the features were done, and all the customer questions were answered, but I realized that I only remember lessons from the features I was really nervous about at the beginning, or I only remember the tough customers that wouldn’t leave me alone. So, one lesson I learned is that it’s good to be nervous/scared about a feature in the beginning, or it’s good to get overwhelmed by questions from a tough customer because in the end, those are the experiences that will help you grow.

Anyway, these are some of the things I learned in 2010. Let’s see what 2011 will bring.


2 thoughts on “Software lessons learned in 2010

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