These days its fashionable for businesses to have a Facebook and Twitter account. I can see how social media can help them. But what beats me is, every now and then, I see a billboard or a poster with just Facebook and Twitter icons in one corner of their printed ad. What does this mean?

Its like having visiting card like this:

Instead of:

At the last SDTConf, Todd Little facilitated a session called “Technical Debt is Really a Lease.”

I had a few interesting take-aways from this discussion:

• A debt always has a notation that you need to pay it eventually (unless you default.) This is not true in case of a technical debt. There might be parts of your code which is a complete mess, but you don’t touch it and its fine to live with that debt. Or you might just decide to throw away that code since it served its purpose. You might never need to pay off that technical debt.
• Deep down in our psychology, the term “debt” trigger a negative thought. We strive hard to avoid a debt. However if you project the same thing as a lease, it seems to have a more positive feel. In the business world, taking on a lease, in many cases, can give you a good business advantage. In fact some might even consider it to be stupid not to lease out stuff.
• The important thing to consider is: what is the “Cost of Service” for a lease/debt? If the cost is significantly high, you are better off not taking it on. But if the cost is really low, it makes all economical sense to embrace it. We’ve learned that long-term, heavy interest leases/loans are a bad idea for that very reason. But a short-term, low interest loan can provide extra working capital to expand business.

IMHO it can really help teams to think of technical debt really in terms of the “cost of service” of a lease.

Beware not to make technical debt a dumping ground for tasks that the team wants to defer without a conscious, thoughtful reason. I’ve seen in many organizations, technical debt becomes an easy excuse for the team to skip things that are very important but for their short-sighted hasty decisions.

You might think Definition of Done (DoD) is a brilliant idea from the Agile world…but the dirty little secret is… its just a hand-over from the waterfall era.

While the DoD thought-process is helpful, it can lead to certain unwanted behavior in your team. For example:

• DoD usually ends up being a measure of output, but rarely it focuses on outcome.
• In some teams, I’ve seen it disrupt true collaboration and instead encourage more of a contractual and “cover my @ss” mentality.
• DoD creates a false-sense/illusion of doneness. Unless you have real data showing users actually benefiting and using the feature/story, how can we say its done?
• I’ve also seen teams gold-plating stuff in the name of DoD. DoD encourages a all-or-nothing approach. Teams are forced to build fully sophisticated features/stories. We might not even be sure if those features/stories are really required or not.
• It get harder to practice iterative & incremental approach to develop features. DoD does not encourage experimenting with different sophistication levels of a feature.

I would much rather prefer the team members to truly collaborate on an-ongoing basis. Build features in an iterative and incremental fashion. Strongly focus on Simplicity (maximizing the amount of work NOT done.) IME Continuous Deployment is a great practice to drive some of this behavior.

Specialized roles suck the distributed knowledge and skill from different practicing heads and tries to stuff it in one central place.

The people who are freed of the additional skill (burden), slowly reduce practicing the skill and day-by-day they become weaker at that skill. Gradually, they are completely out of touch and stop caring about the skill. Ultimately, they start feeling that they are not qualified enough and also someone else with the specialized role is now really responsible for that skill.

The person with the specialized role, is exposed to more situation & starts practicing the skill a lot more. With all that practice, they hopefully get stronger at that skill. But in the process, as they are completely focused on this specialized skill, they care a less about other things.

Over a period of time, creating skill silos, who barely understand or appreciate the other side.

Net-net, IMHO specialized skills leads to local optima and might be good to start with, but not good for global optima over a period of time. The hard part with specialized roles is that once you are down this slippery slope, its very hard to back out.

Dysfunctional organizations with product, design, architecture, development, testing, deployment and production support silos reinforce my believe.

A really strong collaborative culture with collective ownership and frequent role rotation between these silos seems like the only way to rescue organizations out of this specialized role mess.

At the SDTConf, we had an interesting discussion on how to deal with technical debt. The group agreed on the following suggestions:

• C3: Coverage, Complexity & Churn – Instead of looking at each of these parameters in isolation, we generate C3 graph using a TreeMap and use the cumulative graph to see red spots in the product. Esp. helpful to quickly raise awareness.
  
• Slack: Every team members gets a 10-20% time every iteration to invest on things that hurt them.
• Scratch your Personal Itch day: Every iteration each team members gets 1 day to fix unplanned issues on the project
• Visitor from Hell: Every month have one person from other team visit you and give you feedback on various aspect of the team. Its up to the team to address these issues or not. But certainly can be used to pitch to the management for additional time to work on these issue.
• Code Walk Throughs: Every time a team member (or pair) implements something important, they give a code walk through or a demo to the rest of the team. This usually ensures team members don’t have crappy things when they give a demo.

I’m not against Manual Testing, esp. Exploratory Testing. However one needs to consider the following issues with manual testing (checking) as listed below:

• Manual Tests are more expensive and time consuming
• Manual Testing becomes mundane and boring
• Manual Tests are not reusable
• Manual Tests provide limited visibility and have to be repeated by all Stakeholders
• Automated Tests (Checks) can have varying scopes and may require less complex setup and teardown
• Automated Testing ensures repeatability (missing out)
• Automated Testing drives cleaner design
• Automated Tests provide a safety net for refactoring
• Automated Tests are living up-to-date specification document
• Automated Tests dose not clutter your code/console/logs

Found this SEO Raking Factors represented in a periodic table refreshing. Thanks to Search Engine Land for creating this.

You are a startup and you’re building a product. It all sounds exciting until you sit down to decide the product name. Coming up with a public name for your product is one of the early decisions you’ll need to make.

What criteria do you use for naming your product?

I’ve used the following:

1. AdWords: When people want to find something similar, what keywords are they searching for? I would use Google AdWords to find keywords/phrases that people are already searching for. Look for related searches.

2. Competitors: If there are similar products in the market, what have they named their product and what keywords are they focusing on?

3. Unique Name: Based on keywords from the first 2 steps and your own preference, pick a few unique name that communicates the outcome achieved by using your product.

For ex: if I was building a product which helps me search and find my files, I would call the product Found instead of File-Searcher or something else.

Sometimes, you might need to search for synonyms or replace certain characters in your name to make it distinctly unique.

Choose an appealing name. Something that appeals not only to you but also to your target audience. Choose a comforting or familiar name that conjures up pleasant memories so customers respond on an emotional level. Usually long or confusing names are not favourable.

Also try to avoid names that are spelled differently than they sound.

4. Domain Name: Is a .com domain available for this name? Also what about other popolar TLDs? Personally I prefer getting a .com, unless your product naturally blends with some other TLD. Like talk.to You want to make sure your domain name is different enough from your competitors’ domain name.

People generally make mistakes while typing URLs, you need to make sure there are no stupid websites with small variations of you domain name.

5. Trademark: Might be worth checking if your product name is already a registered trademark owned by someone else in the same business domain. Esp. in the country where you plan to sell your product. In the US you can search trademarks on USPTO’s website.

6. Test your name: Its generally a good idea to present your shortlisted names to a few people and see their reaction.

7. App Stores: Even though all popular App Stores allow duplicate app names, it might be worth checking if other apps use the same name. .i.e. if you plan to build an app as part of your product.

Wikipedia has an excellent article on this topic called: Product Naming

Many friends responded to my previous post on How Much Should You Think about the Long-Term? saying:

Even if the future is uncertain and we know it will change, we should always plan for the long-term. Without a plan, we cease to move forward.

I’m not necessarily in favor or against this philosophy. However I’m concerned about the following points:

• Effort: The effort required to put together an initial direction is very different from the effort required to put a (proper) plan together. Is that extra effort really worth it esp. when we know things will change?
• Attachment: Sometimes we get attached with our plans. Even when we see things are not quite inline with our plan, we think, its because we’ve not given enough time or we’ve not done justice to it.
• Conditioned: Sometimes I notice that when we have a plan in place, knowingly or unknowingly we stop watching out for certain things. Mentally we are at ease and we build a shield around us. We get in the groove of our plan and miss some wonderful opportunities along the way.

The amount of planning required seems to be directly proportional to the size of your team.

If your team consists of a couple of people, you can go fairly lightweight. And that’s my long-term plan to deal with uncertainty.