Keeping Secrets

How many times have you ended up publishing a price sheet you did not intend, to be available to your channel ? We have seen this all too often that unintentional leaks do happen. This is especially true when you are releasing a new product. The bad is you may change pricing models at the last minute too and all that explaining may be a bit hard.

Here is one suggestion on how to keep it a secret. Do not create one.

Unless you really created a Price Sheet or a document it does not have to be hidden. That is one public goof up avoided :-)

Since it is much easier to create a price sheet than releasing a product on time, .. keep it a secret.

My Son, My Appraising Manager and Project Management

I am very fond of my son. Who is not :-) Well,  being too fond of them may lead you to irritate them too. When my wife and I sit together for a chat along with my son (just 3 years now), I observed one interesting thing.  He always goes and sits next to my wife more than me. I am not jealous btw, honest. He comes to me but moves away faster than probably he wants to. This made me think. I later realized that I was probably irritating him by cuddling him and not letting him set the agenda :-) Later I stopped doing that and did not even look at what he was doing.  Hey, now I found that he increased the average time spent "near" me.

Now 7 to 9 year back I had a comment from my first appraising manager. I asked what is your feedback about my performance and his reply was, I do not have much feedback, you are doing just fine. I do not want to give feedback and disturb your rhythm. Well I am happy for that.

Got the relationship with Project Management ? If a team is doing well, do not change the working equations. Its very hard to get a set of people to work together on the long run. If the team is doing well, and there are big plans for the long term, then do not tinker with the team. Just let the Project Manager function with independence.

updates for business critical functions vs twitter updates

I have observed many times people are able to make twitter updates with amazing regularity. Stress here is on "regularity" not quantity. But I have seen others who always have an excuse of not having "time" to keep the CRM updated.

Or to put it in another way, it has been hard to make the team do a "business critical" function like keeping the "sales CRM updated" when compared with a "socializing" function like writing personal comments on twitter !

What makes this possible ? I am sure employees mean well. So ...

Well twitter has twitterfox that makes tweeting a breeze. I guess the main reason for this lack of enthusiasm among employees to update a "business critical" function is lack of usable interfaces or in other words the drudgery of existing mechanisms.

So reduce this drudgery and make them more productive by giving them cool widgets and interfaces to your million dollar CRM investments.

Jopr platform for building management applications and RHQ Project

I just stumbled upon Jopr recently and realized it is the opensource version of the JBoss Operations Network - Platform. That could mean any one trying to build a management platform (monitoring applications / servers) say for JBoss itself or other applications could use Jopr to start with. Definition of Jopr from their website : Jopr (pronounced "jopper") is the open source enterprise management solution for the JBoss Middleware projects. This management project delivers an open source and unsupported form of the JBoss Operations Network product. It provides enterprise administration and monitoring with fine-grained security and an extensible platform base upon which extensions and new administration support can be built. This system is based on and plugin-compatible with the multi-vendor RHQ management project Interesting multi vendor project - RHQ, though collaboratively developed by RedHat and Hyperic. Looks like opensouce community feeds in to RHQ while RedHat and Hyperic sells it commercially in another name. Or did i miss something ?

Software targeted at the SMB Market ?

IT Management software products that are generic have lesser people accepting it than products that are targeting a niche space.

Explaing more about above stmt ...

Then answer why - because of maturity of IT org. Ask your sales force why their people do not keep their sf updated ? laziness / lack of process ? Same way complex software will not be used in an organization, even if they are free

What is SaaS for the Big 4 of IT Operations ?

For all of the last 20 years, the Big 4 have dominated the Enterprise IT Management market. They have contributed a lot to the innovation with the level of engagement they had with customers and end users. However a lot of these learnings have become best practices and common knowledge and the barrier to entry of new players have reduced.

However these organisations itself have not evolved with the times and stick to the high cost business model where consultants and marketing teams still play a major role in winning and maintaing customers.

Now with the slow but sure evolution of Software to move as a Service (SaaS), these IT Management vendors are finding it hard to adopt and move towards a SaaS model for delivering IT Management. The biggest challenge for these vendors seem to be :

1) Technology
2) Business Model

Technology Challenge:
The biggest challenge from the technology point of view is their agent based approach to monitoring and the product Client (GUI). Most of the software they use is an agentbased model, which had its benefits in the early days when packaged applications did not have a management instrumentation of its own. Another technology challenge is their outdated Client Interface. They also have to work on a web client to make it work for a SaaS model.

The technology part is probably something they can overcome over a period of time, but ofcourse they have the risks associated with rewriting software code.


The biggest challenge for them is changing the Business Model.


Having being addicated to getting 6 and 7 digit software license revenue , they will find it hard to move to the norm that is come to be seen in the SaaS model - Subscription based pricing. Subscription based pricing involves getting license cost per year and more predominantly on a monthly basis.

The bigger problem is for those who are Public Companies. They can't afford to show a lower revenue for a quarter, let alone for a whole year due to shareholder pressure. This is the case even though it is clear that Subscription model prices even out on the long run.

The movement of applications to the cloud is sure. The dominance of the Big 4 in the past is an established fact. However the emergence of a Smart Fifth is also a possibility;

..... unless the Big 4 and other vendors are willing to be more agile.

Reasons why Subscription Model Pricing is Better than Perpetual Model

Is Subscription Model Pricing is Better than Perpetual Model ? Well I am sure we can argue it either way, but let me give probably some non-obvious reasons why Subscription is better.

Well before that let me define what each is. Subscription Model Pricing is where you charge the customer a specific amount for using your services or product every year or month. In SaaS Services monthly billing ius very common.

Perpetual License Model or "License Model" usually default Licnesing Type and more popular one in traditional software, is where you pay one time for using the software and never have to pay again. This normally does not entitle you for upgrades and support. That comes as an additional.

It is common to have a formula like
Perpetual Model Price = 2.5 Times Subscription Prices + 20% Annual Maintenance & Support

Now what are the not so obvious benefits of Subscription Model ?

1)If you are a product company, by embracing a Subscription Model, you are making yourself ready for the movement to Software as a Service. Normally in a SaaS model, Services are offered in the Subscription Model as seen in Zoho and other services.

2) Since customers pay you monthly, renewals or "subscription money" will bring in a more steady revenue stream in the long term.

3) Since you are paid only monthly or yearly, you do not get access to the whole loot in one go :-) You tighten your spending in the begining itself and hence will eventually have a better run business. This is because lesser money comes upfront and it gives you that discipline in keeping expenses in check.

4) You make a more useful service. You earn the renewal money by making your customer happy. This is really critical as when you see users dropping off, you know your service is lacking. You can take immediate action. This added advantage helps you creating a better product in the end.

Code Rewrite : why it is bad ?

Well what is code rewrite ? It is a strategic decision to scrap all code you have ever written for a software product and rewrite it from scratch, thinking that will give you better quality code & will be easy to maintain.

Stay away from rewriting a whole code base thinking the old one is terrible.

I have personally seen that being a bad decision many times. Joel on software has very interesting real stories to tell here.

Why it is bad ? Here are some reasons I have felt -

1) Lots of developer effort going down the drain.
The old code base say it was 3 to 5 years old has had lots of development effort already go in. Notwithstanding while writing the new code base do you have better developers and designers than what you had previously ? Otherwise you could end up with a code that may no seem readable and hence maintainable but not really superior.

2) Quality Assurance person's time. Your QAs would have already done lots of testing. Now, to get back a fresh piece of code to that quality is not a simple task. Have you documented all test cases / use cases ?

Fresh Code to reach the quality of Old code with all Use Cases handled will take time.

3) What about the hundreds of invaluable testing already done by customers ! Think about it. There are lots of customer environment specific issues. How did you fix it or what was the fix ? Can you reproduce that in your labs and support it ? BTW those 100s of small enhancements took that extra week each to support.

4) If you are going to maintain the old one too, then its going to be a bigger nightmare because you are going to distribute your work on 2 code bases. That is going to slow you down.

5) Remember Customers do not buy your software after reading your code. But they want the software to work, otherwise they are going to complain. Complain real loud.

6) When you rewrite code, cultutrally people expect a better featured product from what was previously present. Most people comment on the GUI as that's all they really see. Now these expectations futhur increase the time taken to go to market.

Ofcourse code rewrite for a small piece of software is absolutely fine. The above post is more from a perspective where there is a major rewrite from scratch of a full software product maybe which had over 500 man years of development effort.

So what should I do when I have feel there is a need to rewrite code ? Well Follow the 80 - 20 rule. Most probably 80% of the problems are caused by 20% of the code. Even here first identify the problematic code and be very straight to the point on how you fix. Do only Design fixing where it is absolutely needed. Fix only the flow problems or the design problems - meaning creating interfaces, and deciding on the right approach etc and donot take up anything that does not need to be touched. Do not evaluate new frameworks especially for DB persistence etc. Also look at the revision history. If the code has not been touched for years, then you may not have to even change it as it is actually working.

To summarize I guess code rewrite is bad especially for large projects. The main reason being the difficulty to get the new code to reach the quality and richness as the old.

About this blog

This blog is going to talk mainly about Performance Management, Product Management, SaaS, Application Performance Management, Business Service Management and other interesting things that I come across.

Please note this is a personal blog and the content I write in this blog does not represent the company I work for.