For software practitioners like you and me, we focus too much on the software part of the product lifecycle – the architecture, design, coding and testing. But there is a whole another world out there, where you have to get real users to like and use your product. Otherwise, it will end up unused and finally discarded.

However useful the product is to end users, you have to invest significant amount of time in marketing. And the term “marketing” is not as simple as it sounds. It is not about a big TV spot or full-page newspaper ad. It is informing, attracting and keeping users through many channels, including the fore-mentioned TV and newspapers, but also through building references, communities, and partnerships.

Product improvement is also a huge part of the marketing process. If you start with a few users, how do you maintain their interest and keep them coming back? How do you improve the conversion rate of users who visit your website and do not sign up? How do you cater to users who are looking for more?

So, there is no endpoint for the development effort. You can create a plan for development and complete the features. But the story doesn’t end there, because you have to continue to put the effort, even if it is simply to upgrade and scale the application. This means you have to produce on a regular basis. If you opt for a big-bang approach of finishing a ton of features, users will simply leave you behind.

1. Every person works on tasks that will maximize the benefit to the team.
2. Even if they are good at other tasks, they focus on tasks that bring the greatest value.
3. They delegate those other tasks to people who could do them less expensively.

For example, even though the software architect in your company could be the best coder in the company, you don’t want her to sit all day long writing HTML code. Her talents are better used in design and architecture. So although there are several things she could do better than anyone else, she is used in the tasks that bring the greatest benefit to the organization.

Unfortunately, at an individual level, many miss this point. They spend their time being busy in tasks that could be easily delegated to someone else. Usually, the reason given is that they are the best at that particular task and/or if they give the task to others, it would not be done perfectly.

In reality, this results in a huge opportunity loss. By taking on such mundane tasks, the person is unable to spend time on more value-added jobs that has greater benefit to the project and organization.

Most people do this because they are scared of failure. What if the delegated-to person messes up the task? In my view, that is only a valid excuse if there is very little room for failure. For example, if you (as a manager) have to make a presentation to a big prospective client tomorrow, it is not a good idea to simply rely on a tester – you probably should do some smoke testing yourself.

On the other hand, in many situations, you have the ability to tolerate some failures and have time to train people. And that is where you should start delegating tasks. Yes, there will be mistakes, but you can point that out. If you have a person who has the ability to learn from their mistakes and follow processes, things will get better over time.

My answer is: In terms of direct business benefit, generally “No” and sometimes “Yes”. The main beneficiaries of “Free” are consumers. Instead of paying for something, they get it for free now, the cost being subsidized by advertisers or other products of the vendor. In some cases, the cost is written off by the investors. “Free” only means no cost to one party in the transaction, it doesn’t mean that there are no costs per se. Somebody is incurring them and is either profiting via other means or losing money.

So, the question is, if you are a producer, how do you profit by giving away your product for free? At the moment you stop charging, you lose the revenue from product sales. So you only benefit by making more money via other means than you have lost by forgoing direct sales. GPL introduces a different complexity – you can still continue to charge for your products, but there is nothing stopping anyone from making unlimited copies of your software and re-distributing them for free or for a fee, perhaps not sporting, but legal under the GPL. Once again, can you make up for the reduction in revenues?

It is possible. The idea is that by making your content free, you reduce friction for your consumers and buyers. There will be more consumers of your content if it is not hidden behind a subscription wall. A GPL-based product is more attractive to users who can modify it for their needs without depending on you. You will gain more publicity and can drive traffic to sell other products that are not free.

But what if everyone does the same? What if all news were free? What if every software product was under the GPL? Suddenly, there is no special advantage being free. “Free” is therefore only a marketing tactic. And other free competition can erode that advantage.

The other rules of the marketplace also apply in “free”. “Free” removes the problem of cost from consumer consideration, but it does not solve time constraints, inertia, network effects, etc. For example, we often hear about the GPL success stories of Linux and mySQL. But there are other GPL operating systems and database applications. Why are they not successful? The reason is that the success of Linux has ensured that other free operating systems do not find the same success.

Take a look at WordPress. It has been extremely successful under the GPL. But no other blogging engine licensed under the GPL can replicate WordPress’s success. WordPress has built a huge eco-system (themes, plugins, etc.) around it that no other GPL blogging product can replicate. This is not to trash WordPress in any way (it is a great product).

Essentially, what this means is that the products in any space that benefit from a GPL license will drive out other GPL products in the same space. Similarly, the websites that benefit from giving away their products/information for free will drive out other such free sites. “Free” can allow you to gain a competitive advantage only for so long, because it can be imitated, so you must drive home your advantage while you can.

In some industries (such as news), there is no alternative to free. But it doesn’t mean that every news outlet which becomes free will be successful. Likewise, giving away your products for free or open-sourcing your product doesn’t guarantee success. It is generally beneficial to consumers, but not necessarily the producers.

Regardless of what is actually more important, time overruns are usually treated as a bigger problem than cost overruns. Missing deadlines is an immediate problem. It is in your face. It is very objective. In contrast, cost overruns require greater analysis and deviations can be smoothed over or explained away unless the variations are very large. So, meeting deadlines is usually treated as the most important objective for a team.

When you meet an immovable object, you have to give way. If deadlines cannot be changed or compromised, then something else will have to be gone instead. This should be best accomplished by reducing the feature set for the deadline release, but sometimes, at the individual level, quality takes a step back. Sometimes, the reduced quality may be imperceptible, but over time, it adds up to a poorer system that is less maintainable and less extensible.

If you want to fix this, it is necessary to change the emphasis from “meet the deadline” to “meet the quality standards“. First improve quality, and only then examine productivity issues. If you try to improve productivity first, quality may decrease and also reduce net productivity as the team is pulled into fixing quality problems.

But as I started saying, when you try to improve quality, you will initially see a reduction in productivity as the quality activities take more time. There might be refactoring that takes time away from new development. So here is where the project manager has to show leadership by avoiding compromises on quality while the clock keeps ticking. She may have to buy more time for the team to improve quality. It may be tough sometimes with external deadlines looming, but that is what is required for quality improvement.

The quality of an audiobook depends on how good the narrator is. And this has less to do with how good the narrator’s voice is than how well they know and like the material. Sometimes, a narrator has a good voice, but they fail to put emphasis or show enthusiasm at the right moments. The best narrator is usually the author unless they are terrible at speaking. Assuming that the reader is familiar with the material, their voice, accent and other speech patterns play an important part in how you will enjoy them.

Most of the time, you will not hear the audiobook at one shot, it being spread across multiple commutes. This is also a problem with hard-copy books, but you have the luxury of flipping back the pages of a book easily if you forget something. In an audiobook, that is not easily done, so the better audiobooks are the books that have themes and ideas that last longer and anecdotes that are shorter. This also helps if your attention is diverted during driving.

Some people recommend increasing the audiobook speed to listen faster. This works only if the reader was not speaking quickly to begin with, otherwise you get distorted words and meaning. I find even normal speed difficult for fiction audiobooks, because fiction is more complicated than non-fiction with complex plots and multiple characters. Unless the novel or story is presented by multiple voices representing the various characters, it is difficult to make out what is going on.

In non-fiction, books dealing with topics of business management, projects, innovation, etc. have good audiobook versions. Even though you miss some of the tables and charts that comes with the regular book, it does not prevent you from understanding the book. I haven’t heard any books on software topics, but I suppose with the greater use of visuals, they may not be as accessible in audio format.

It’s important when we introduce something new that we spend some time figuring out what the people around us need to be successful. These folks have families… they have kids in college… they have financial obligations. You are not just asking them to change… you are asking them to put their livelihood at risk. People don’t resist change because they are bad people or because they just don’t get it. Chances are… at some level… they are afraid.

More than likely… there is some fundamental concern that you have not addressed. Until you understand what your detractors need to be successful… and work to satisfy that need… on their terms… they are going to continue to stand in your way. They will continue to hold you back and resist the changes you are trying to implement. If you had so much to lose… you’d probably do the same thing.

Trust me doesn’t cut it until you have earned that trust. Agile will help you get there… but you know what… you might have to let them have their Gantt chart… you might have to let them have their MRD… until you can make it safe for them to let it go.

This is applicable not only to Agile, but also any new processes that you introduce into your team or organization. I wanted to add one important point: The people who are standing in your way just feel uncomfortable, but they do not know why they are uncomfortable for the most part. Maybe there are people who actually think, “I have to oppose this because I will lose my job“, but generally speaking, they just know that what you propose is not going to work, even if they like you and trust you.

And such thinking is perfectly rational. If it wasn’t, you would have managers who go the other disastrous way of adopting every new business fad that catches their attention. There would be no stability because there would only be moving targets. Even a good methodology like Agile would fail because they will keep tinkering with new ideas instead of sticking to a gameplan and seeing it through.

So, think of “some” opposition as a good thing. It means that when you break down the opposition, the change is likely to be more permanent because you have convinced people of its benefits and addressed their concerns. You would also have learnt how you must adapt the change to the needs of your team or company.

Gradual change is the change that lasts. So be patient.

The cause, I think, is that people confuses higher quality now with the transition from low quality to high quality. When your software development team is already working at a high level of quality, you are already saving time and money by avoiding rework and having to fix costly bugs. Maintenance is easier. Adding new features is done faster. So things are good.

But when you are trying to move from your present quality level to a higher quality level, there will be transition costs. This includes the time and money spent on quality personnel, training, new processes, documentation, piloting and so on. And even the best of transitions will involve irrecoverable losses because of mistakes made during piloting and tailoring the new quality processes.

As an organization, you need to budget for these transition costs and have an understanding (formal or informal) about the return on investment, i.e., how long will it take for these quality initiatives to start paying for themselves. Such an exercise can also help you accelerate the launch of the quality initiatives that can offer the fastest bang-for-the buck. For example, while both are important, code reviews have quick returns while automated testing has a more gradual return on investment.

So the real argument is, “Improving quality will cost you in time, effort and money, but it is an investment for the future with some immediate, but other long-term benefits. And here is how and when it will pay off.” That is much more meaningful and truthful. And it has a much greater chance of being accepted by a business manager.

1. Don’t ask them a question when they are unprepared or under-prepared to deal with your request.
2. Don’t ask them a question when they don’t understand your expectations of a reply.

Other people don’t live in the same universe you do and they definitely don’t have the same thought processes you do. They have their own targets to meet and issues to resolve. Unless their only job is to be idle until you call upon them, when you interject your request without any warning, the first inclination for them would be irritation and a wish for you to disappear.

So make sure that you choose the right time to ask something of someone. Give them enough room to take care of whatever urgent matters are occupying their thoughts and then be able to handle you. One way to do that is using an asynchronous medium such as e-mail to give prior warning or asking time to schedule a meeting to discuss a matter. Calling someone out of the blue and jumping directly into a request has a high probability of getting your request shot down.

Second, if people don’t understand what you are trying to do, they will always give the direct answer to your question, instead of finding ways to help you. For example, if you want a friend to help you with some house work and you ask him, “Do you know electrical systems?“, it is likely you will get a “No”. Instead, if you tell the friend that you are looking for someone to help you and then mention specific things, the friend may find some common ground and agree to help you.

Or in a work setting, if you ask an engineer, “Can you get this method down to 0.01 seconds?“, the answer may be “No”. But maybe the right question, “How fast can you get this method to run?” and the answer comes back as “0.05 seconds”, maybe that is something you can work with in combination with other factors that you can tinker with.

In more simple terms, ask open-ended questions that focus on the problem, not on the solution. When you do that, you may get solutions that are even better than what you originally thought of.

• I will do it when I find the time.
• I will do it when I don’t have any other responsibilities.
• I will do it when the stars are aligned.
• … etc.

The problem is that you will never find an opportune time. There will always be work to do, bills to pay, responsibilities to attend to, family members to take care of and a million other things. As you keep waiting, days go by. And the days turn into weeks, weeks into months and suddenly years fly by and there is a different face in the mirror.

Instead, try to make some progress every day. If you are writing a program in your spare time, try to complete something on a daily basis. Maybe it could be a simple screen, or it could be a database method. Or it could be refactoring or a test case. Or checking if the labels are aligned or have the right spelling. Every bit you do counts towards the final goal.

Second, realize that nothing comes without sacrifice. If you want to lead the exact same life that you had previously, the new venture will not fit in. If you still continue to sleep 9 hours, keep the TV on all the time and spend the rest of the time partying and enjoying life, don’t be surprised if there is no progress. You will have to give up activities to achieve your greater goals. In some cases, you may have to give up some of your friends. In simple terms, there is no free lunch.

Last, the present trajectory of your life is determined by factors such as your job, and your family. And if you have a different dream, that, by definition, has a different trajectory. The point is, how much effort are you spending on each path? And are the efforts on the first path taking you closer to or farther from the second one?

I have been noticing the reduced frequency of many bloggers that I follow. Perhaps the pervasive use of Twitter has contributed to this, because what used to be a post is now a Twit. This is perhaps a good thing as it raises the quality of the average blog post. But at the same time, it moves the attention of the blogger away from writing longer posts, the cycle feeds on itself and the frequency keeps going down.

Writing, like other creative activities, requires momentum. You cannot just turn it on and off. The more you write, the more you are inclined to write. If you stop for sometime, it is harder to restart the process. They talk about writer’s block. It is much more difficult when you haven’t written anything for a while.

Another problem is that when you have a gap, there is an added pressure of producing something of higher value than usual. Perhaps like an actor who took a break and wants to pick a movie that is sure to become a hit. This means further delay as the selection process continues ad infinitum. On the other hand, if one is writing frequently, there will be good ones and bad ones, and you are generally more concerned with the process than the outcomes.

One aspect specific to writing about software development is that after a while of writing, you get a sense of déjà vu, as you go over the same ground and topics. Sometimes, it also seems that you are beating the same point to death. Part of keeping it interesting is to be able to keep a broader mind and keep looking at new developments and ideas.

Obviously, software development is a highly innovative field, but a lot of the innovation is in the tools such as languages and frameworks. The overall process of managing software development doesn’t change so quickly. And it shouldn’t, really, because it would mean an unstable working environment with the managers trying the latest management fad. That partly contributes to some of the repetitive themes in blogs.

And of course, life happens. Writing a blog is generally a labor of love for most people who are not paid to do it and don’t have ads (like this one). And you do it juggling time between work and family, snatching a few extra minutes at the start or end of the day or during a weekend. Sometimes, there is not enough to juggle.