Last minutes changes

You’ve spent a week or two working on this feature. You’ve spent time testing it and everything seems to be working well. You have a launch date set and it’s finally the day to deploy.

You go over all the updates one last time and discover a few things which need to be updated. Last minute changes are almost never welcome. Do you hold the launch or launch it knowing that the feature is missing a few details?

Facing the exact situation yesterday, I decided to do the latter. Launch, knowing that the feature is missing a few details. If the changes were critical I would have delayed the launch but these were not critical changes.

The good part about software is that you can always roll out the next update the same day. I am updating the feature again today. All the issues from yesterday’s list are now fixed.

Fighting against a current habit

If you are building a B2B software application you are fighting against a current habit your target customer has. In most cases, it’s either email or excel sheet. These two tools can be used for a variety of purpose and are used every day by a lot of people.

Why would they want to switch from something they use every day to your tool? From something they are comfortable using and don’t have to spend time learning to learning how to accomplish a certain task in your tool? These questions are worth thinking about.

They are indeed looking to switch to something better, but as soon as they face any issues with the new way of working with your tool, they will be quick to move back to the tool which worked well. Email and excel have been around for more than a decade now.

When you say your software is better, makes it easier, helps streamline and provides a unified view, I hope you also consider making it really easy to get started with. As easy as email and excel.

Reviewing Code

Not sure when reviewing code became a habit, but it is now part of routine before deploying new code to production.

Git diff is really helpful and lets me know of the new code being pushed.

It always surprises me that during review I notice conditions or logging methods that I missed adding to the code. There are less surprises and errors in production environment.

I use Beanstalk to deploy code to production and would highly recommend using this, if you are still deploying code via drag n drop using a FTP client.

Quit Social Media

My research on successful professionals underscores that this experience is common: As you become more valuable to the marketplace, good things will find you. To be clear, I’m not arguing that new opportunities and connections are unimportant. I’m instead arguing that you don’t need social media’s help to attract them.

Quit Social Media. Your Career May Depend on It. -

I have been thinking of quitting Facebook for a while and the article makes some valid points.

My facebook usage has gone down considerably. Too many articles / memes being shared rather than facebook answering the question of what my friends are upto.

Time Estimates

Programmers are often said to be optimistic about how long a feature / software takes to develop. I am constantly reminded of how true this is.

This week I thought a lot about time estimates and why I am often wrong with my time estimates.

It comes down to the need to please the person asking for the estimate. The expectation that the person on the other end wants it done as soon as possible and giving a short enough time would make them happy. An approach I am going to rethink from here onwards.

Dilbert Comics

In larger organisations, a project manager is usually involved in arriving at the final time estimate which includes some breathing room the programmer forgot to budget for. But even then most enterprise projects spill over time and over budget.

Here are some ways I am going estimate time from here on:

  • Understand the scope of the feature / software you are asked to develop.
  • List down all the small components of the feature / software to be developed.
  • Is there a third party company involved? Budget for extra waiting time for when you need some information from them.
  • Is there a new language/ tool you need to learn to get the work done? Budget for time to learn and for those moments when the new tool just refuses to work.
  • Budget for life in general.
  • Are you working on multiple projects? Budget for time when one project takes up a lot of your time, leaving you less time to work on the other project.

Scope changes are part of software development lifecycle. When there is a change in scope, communicate this with person on the other end about how it affects the previous time estimate rather than trying to get the extra work done in the same amount of time.

Better Defaults

Working on a new feature is always a good learning experience. One of the learnings today was the need to set better default values.

Could the user accidentally stop a timer before 1 minute? Not many would want to record time less than a minute. Rather than display an error message, it would be better to automatically update the timer entry to a minute.

The default theme, font, text size and so many other decisions you take when building your product end up making a big impact on end user experience. Not many would look under settings to change these values. Good to have an opinion about the default choice you decide on.

Work Smart

Life is Short. Work Smart. Have fun.

That’s the slogan of Brightpod, a project management system for digital marketing agencies. If you are looking for a online product to manage your projects, give Brightpod a try.

I have been thinking about Work Smart part of the slogan this week. What does it mean to Work Smart? Do you have a process in place on how you achieve your work? Do you use smart tools to get work done? Do you not juggle between projects when working?

Working smart for me is having a fixed list of tasks I need to complete each day. I set priorities for things I want to get done on a given day, leaving room for small new additions to the schedule. Things on lower priority can move on to the next day, but no further than 3 days from when it got added to the list.

Working smart also means setting boundaries for what you say yes to in a given day / week.

What does Work Smart mean to you?

P.S: Happy Birthday Amol!