Continuous Learning

Below are the web clippings of the day. Enjoy.

• Stevey’s Home Page - Being the Averagest
  
  Can you tell if someone is a great developer? Or is he/she just one who is very used to do things a particular way who never thought to improve beyond what he/she already knows how to do?

• Why you cannot learn much from past success - lifehack.org
  
  People really learn more from mistakes and failures than from successes.

• Creating Passionate Users: Are our tools making us dumber?
  
  The title says it all - are we becoming less capable because our tool are doing the work for us so we don’t have to think? When was the last time you did calculations by hand and do you still remember? I sure don’t

• Rands In Repose: 1.0
  
  Rands has an interesting model to look at version 1.0 companies and why it almost always fails. IMO the more technical the founders are, the less gap between pitch and product and the more likely it can succeed.

• So you want to be a consultant…?
  
  What it takes to be a consultant from someone who has been doing it since 1985. IMO, this is what it takes to be a professional, period, regardless of the status (i.e. employee, contractor, consultants).

• Creating Passionate Users: Don’t make the Demo look Done
  
  How to set the right expectations with stakeholders/users/etc on the current progress of the project through demos. If one uses polished demo early on, things will look done and the feedback will be minimal.

Below are the web clippings of the day. Enjoy.

• The Software Construction Analogy is Broken || kuro5hin.org
  
  An earlier attempt on breaking the myth that software = construction. It is probably getting close for the 3rd installment of the series

• Comcast Customer Uses “Unlimited Service” Excessively, Gets Disconnected For A Year - Consumerist
  
  A classic text book example on what not to do with customer services - it will be a while before Comcast can live this one down. Free tips for ya, Comcast - use throttles to control user network access, not network polices.

• Comcast Responds To Disconnecting “Unlimited” Customer For “Excessive” Use - Consumerist
  
  Yet another textbook example on what not to do to repair damaged customer relationships - deny any wrong doing to look good and do not proactive look after the claims customers make.

• Creating Passionate Users: Your user’s brain wants a conversation!
  
  Why it is important to write the way you talk, not write the way your English teacher teaches you to write - most of them don’t make a living writing

• The Fire Your Customers Myth
  
  Is firing customers a good choice? It depends on how you do it. A bad customer relationship can come back to haunt you given the importance of good services these days.

• The worst IT worker in the world � Angry 365 Days a Year
  
  Mr. Angry hits it on the head on the type of IT workers that have difficulties getting along and making impact in IT enviornments. Communications and customer service attitudes are critical for IT people success.

• Seven steps to remarkable customer service - Joel on Software
  
  Joel Spolsky describes his experiences on how to improve customer services. Going against the outsourcing trend, it is more important to fix the actual problem long term than to have low per instance support cost.

Below are the web clippings of the day. Enjoy.

• Is It Worth Being Wise?
  
  What is the difference between wisdom and intelligence? Paul Graham analyze the question in depth to tell us whether it is important being wise or not.

• Software Engineering Proverbs
  
  A collection of proverbs that provides a glimpse of truth in software engineering fields

• Defeating Procrastination: Analysis Paralysis
  
  Similar to Ready, Fire, Aim - describing the concept of how to start the ball moving, rather than staying in analysis phase forever and get things done. Deadline driven.

• The real secret to a successful blog/book/business…
  
  Kathy argues that the real secret to a successful business is a simple labor of love. It seems that this love would work if it’s love of the users over the love of the craft itself.

• Don’t ask employees to be passionate about the company!
  
  If employee are passionate about their profession and what they do, the rest will take care of itself. Smart companies will stay out of the way when finding such employees.

• Managers and developers: Are you two teams or one?
  
  Trust is the critical issue for project teams, and in software all too often management & developers do not trust each other. The question is - how to build the trust?

There are some interesting posts lately about what programmers like and don’t like to do, and what programmers can’t do. If the below are all true, just what the heck do programmers really do?

I will let you be the judge

Scott Rosenberg says programmers like to code:

And programmers, as I quote Larry Constantine in my book, programmers are programmers because they like to code — given a choice between learning someone else’s code and just sitting down and writing their own, they will always do the latter.

John Rentzsch responds saying programmers don’t like to code:

… they like problem solving.

If programmers liked to code, we’d all be writing in machine language to this day. You can write that stuff all day and get precious little of the real problem solved.

Rafe Colburn says even good programmers can’t avoid coding more than necessary:

I am busy hacking away on a new theme (based on Chris Pearson’s Cutline), and that is why I have not added much content right now.

Below are some of the tips I found out when trying to hack CSS:

• Use multiple lines with each style: when there are multiple declarations on a single line, it is hard to tell how to modify it, especially when viewing through a SSH terminal. While it might look nice on a 24 inch monitor (I would assume most designers would have the best monitors they can buy, it is still easier to scroll down than scroll left or right.
• Use CSS Validator to know whether your change is valid: W3C’s CSS Validator is very handy in telling you where things are wrong. I quickly found a few errors that would have been hard to spot in a 700 line file with the service, and it also comes with a badge once your file passes the validation
• Use @import liberally: @import helps you to break up a monotone CSS file and bring some modularity and organization to keep it from growing into a monstrous beast that would be difficult to maintain. I am glad that CSS has such a facility, otherwise I would have to build one
• Understand CSS inheritance rules: Coming from programming background, I think more in object type inheritance than container inheritance, and run into troubles hacking CSS until I realized the differences. Understand the concept will save you time
• Keep references handy: There are just too many CSS properties to remember for a casual web designer. Luckily the web has a ton of such information I found W3CSchools works well for the basic references and can serve 80% of the needs. And sometimes digging into the actual spec source is inevitable, but those situations always provide invaluable learning.

Today’s web clipping has a shipping theme to it.

Shipping Isn’t Enough

Instead of measuring by shipping code, true success only comes from having users.  And that means developers should do things outside of "coding".

A smart software developer knows that there’s no point in writing code if it’s code that nobody will see, code that nobody will use, code that nobody will ultimately benefit from. Why build a permanently vacant house?

…

Things like documentation, interaction design, cultivating user community, all the way up to the product vision itself. If you get that stuff wrong, it won’t matter what kind of code you’ve written.

Great point, and one often missed in many corporate environment where no one is empowered to do anything, as pointed out by Mike…

We are not talking about Software as a Service here, but rather selling services to produce or customize software products. For tax purposes, government lumps anything that they have not categorized as services. It means just about anything can be called services, so we will not exhaust the possibilities. Instead, we will focus on the following - Add-ons, Consulting/Customization, and Custom Development.

Advantage

Compared to software product models, the enticing part of software service businesses is the lower barrier to entry and potentially steady revenue. You can start a service business as long as you have marketable skills and can find customers.

Disadvantage

There is almost no scale of economy in services models. Unlike software products, where you can build once and sell a million licenses, in software services, you pretty much get paid by the number of hours worked. There are some exceptions, of course, and we will discuss them below.

This is of course THE business model for the past decade. If you were are not on the internet, then you were not viable as a business

The best thing about internet is that there are no rules, and you can do anything you want. In fact, many internet companies are not software companies or even technology companies. Many do not even differentiate through technology and yet still makes money. Many do not even sell you anything and offer free service. Yet they flourish.

Formula

The general formula is to generate traffic. The more traffic you have, the more likely you will make money. Most follow the approach to give something for free first to generate the traffic. A good mantra is to “give first and you shall receive“.

A few different ways to generate traffics are

• Portal - offering wide variety of content
• Search engine - offer targeted content
• Content-led - specialized site offering specialized content to increase stickiness
• Community - let customers interact with each other to create a sense of online community via forums, newsgroups, or other type of social software
• Viral - leverage customers and use them to market your services; often build-into the software itself (such as hotmail)

This is the third article in the Software Business Model series.

While software by nature fits the mass volume model, some software are only needed by few individuals or companies. In such case we must sell the software at a high price point in order to recoup the cost. And this is why we have the business model of Enterprise Software.

The main difference between enterprise and shrinkwrap software is that enterprise software by definition is low volume and high price point. After all, there are just not that many corporations around. Furthermore, corporation generally protect themselves through myriads of procurement procedures, which drives up the cost of selling for vendors, and that add to the final price points.

One thing to note is that few enterprise software are used as is, because they just are not that useful by themselves and require customizations. We will talk about the customization aspect at a different article.

IMHO, there are two specializations under the Enterprise Software Business Model - Platform Software, and Business Process Software. While one can equate SAAS as an Enterprise Software Model, we will discuss it under the Internet Software Model in the next article.

Platform Software

While one might argue platform software are shrinkwrap software, I differentiate them not because the nature of the software but rather than business model of the software. For example, Microsoft Windows is sold both as shrinkwrap and as Platform software.

The Simplicity vs. Complexity debate rages on, because the topic strikes a nerve for many usability and design experts with the following question:

Does simplicity sell?

This question, having coming from a leading practitioner, Don Norman, hits a bit too close to home for comfort. Design experts have been preaching the value of simplicity, user friendliness, and elegance for ages. If it does not sell as well as simply adding features, are experts still adding value?

Reading through some of the responses it is clear that most people believe the simplicity definition offered by Don or Joel Spolsky either as incorrect or incomplete. Few people equate Simplicity as lack of features. Instead, many choose to elevate the meaning of simplicity to “making complex look simple”, or “better user experience”. Below are some of the points that I’ve picked up:

• Striving for simplicity is less important than adding features - Don
• Simplicity in the sense of lacking features is useless - Don, Joel Spolsky
• Simplicity means better user experience - Joshua Kauffman, Mark Hurst, Scott Berkun
• Simplicity is HARD and COMPLEX to achieve - Nick Bradbury, Luke Wroblewski, Michael Zuschlag
• Many offers tutorial on how to balance complexity with simplicity, John Maeda, Nick, Luke, and others

So - who is right?