Wednesday, February 15, 2017

Businesses and High IQ executives often forget this

Businesses and High IQ executives often forget this.

Cash inflow vs outflow is most important metric than anything else, for a long term sustained healthy future while being conforming to social greater good and ethical discipline.

Having too many micro metrics can often take our eyes off the future cash inflow metric.

Planning, innovating, working and sacrifice today is only for brighter future cash inflow.

Not starting with cash flow metric, is a symptom of defocus taking over to kill, in a high wire performance tracking board meetings.

Every action in the organization is for sustainable today and brighter tomorrow.
High IQ executives often device dozens of performance indicators. Their analytical madness often finds intellectual entertainment in discussing numbers. That's good, provided they first focus on the most significant single parameter that influences market share or valuation or direct revenue or profitability, the cash inflow now and in future.

Surprised? but many organizations close down because owners and executives follow their own beliefs of improvement parameters than a simple cash inflow today and in future thing. Completely lost in their fifty odd meaningless parameters.

Any other metrics without this are entertainment invented by management and CXOs for themselves.

Sunday, January 15, 2017

What takes Organization and Civilizations down

People want to make you and everyone in the company busy 
because they don't know "What exactly should be done now", 
instead they want to "try everything". 

Be on high alert for such people
they take Organization and Civilizations down

Monday, October 24, 2016

What does a Manager do?

What does a Manager do?

Of course "Manage".

Manage what? 
Something that needs to be done or delivered in absolutely certain manner!

Dictionary meaning:
"succeed in surviving or in achieving something despite difficult circumstances" 
"succeed in achieving or producing (something difficult)."

What is to Manage against? 
Risk of not able to do or deliver thing against various agreed parameters by keeping constraints intact.

e.g. Quality, On time, Cost, Completeness, Correctness, Reliable, Acceptable, Legitimate, Certainty, Precise, etc...
Guarding the most obvious and important delivery parameters first
Essentially the question is, 
What happens when "management" happens? 
It is "Risk Free Delivery".

A manager has "Managed well" 
when he has managed all the risks "well".

There are internal and external factors which interfere with the agreed delivery

Manager has to "Manage" against all odds about, how will he factors and overcomes every obstacle
Planning, Risk Mitigation, Estimation, Communication, etc. are tools to help "manage"

These tools also need to be used correctly. 

e.g. Realistic Plan, Well thought Risk Mitigation, Correct Estimation and enough times repeated, Overly Simplified Clear Communication,...

So there is science in using and talent or art in applying these tools
Manager must be rated on results not on efforts!

Managers metrics is, 
What risk emerged, 
How he handled it, and  
How deliverable achieved as per agreed expectations

If no risks emerged, then it was easy task!

So Manager's true performance is, 
when many issues emerged and he did not let delivery affected

More capable managers have more capacity to deal with many and very high risks situations successfully

Leader is more of leading the change for better for everyone and together
He identifies the need and initiates the change process

While Manager is required to take care of every risk to ensure deliveries happen as expected

Individuals and organizations value system, social and legal norms gives boundary framework to carry activity of "Managing" something
otherwise "managing something" can take form of "bribed to get it done"

Manager is for doing things in a right manner that covers all risks against expected delivery

Science of Management is about how you get Right in the Manner.

Thursday, September 22, 2016

Biggest thing we should be doing

Biggest thing we should be doing is appreciating peer functions.

Without their presence we could have not done anything.
We crib often for what they failed at doing for us, but that was just a small thing compared to what they doing perfectly well but are invisible because our pain is gone.

Good performance is always invisible.

Wednesday, September 7, 2016

And you can make another fundamental mistake after reading Netscape story

And you can make another fundamental mistake after reading Netscape story
Here is famous Joel’s thoughts on Netscape Story.
Half or more of tech world has something to learn and follow from Joel.
After the impressive comments from Authority like Joel, others build their opinion about code rewrite, almost in fixated manner without considering how different situation they are in compared to Mozilla.

If you are in coding for some time and do not know Netscape’s rewrite case… this post will be irrelevant to you.
Netscape made mistake at most crucial time to waste 3 years in browser rewrite giving a winning chance to IE to come from nowhere and catch to become leader.
Netscape code was working. It became better and better through numerous workarounds and fixes written to survive the various Operating Systems bugs. This was built over a long period. It was scattered everywhere in the code. It was the real IP of the Netscape code that it can work in spite of so many severe issues in memory management, APIs functioning etc the Operating Systems had.
Possibly you could have written a very good HTML renderer browser but that would not work well on Operating System that runs it. So you have to fix for others bugs. And this is most difficult thing that a coder would ever want to do. You don't know what to fix without someone unhappy and reporting it.

Think of this as through an analogy.
The HTML coder your company has, wrote a correct XHTML code. But it does not works well on various versions of the browser. The HTML coder did not violate any of the HTML or CSS standards. Now what he has to do? Case by case for specific browser versions, create CSS, HTML and JavaScript that would work correctly.
So you got the point here. The HTML coder has to patch for issues in browsers to make his web page render correctly.
Let’s go back to Netscape case.
Was Netscape browser rewrite and waiting it to release to public for 3 long years was wrong? Simple Code Refactoring activity could have fixed everything. True.
Why was that required?
  • Poorest maintainability of the existing code due to bad logical arrangement of code.
  • Lots of boiler plates damaged logical integrity by damaging earlier simple structure, introduced redundant and wrong place fixes.
  • Now the situation is, it takes time to change anything because system lost maintainability charm.
  • As it is too difficult to understand for someone to make any change for better.
  • Fixing here breaks at other unexpected places.
  • Many unexpected ways system was maintaining its working.

But the reality was,
Netscape Browser was working well in spite of all OS issues.
Others would certainly need time to catch Netscape. It was working irrespective of thousands of bugs in the systems on which it runs. And Netscape could run on such diverse systems by fixing all such many issues.

The biggest argument made against was, code was not at all maintainable or understandable easily because the state it was in.
Because of bad code, for Netscape, eventually features took really too long to build because it is so difficult to add or improve things for developers. Even any new change breaks the system at many unexpected places. Nobody had neat idea what is in the code.

Netscape was wrong in its approach to fix it.
When you meet a monolith code, you are in mess. That’s why good architecture and design helps by separation of concerns to make it independent of developer’s maturity in code writing.
For Netscape, a simple refactoring by rearrangement of code could have been done easily. Certainly taking less time compared to 3 years, and without losing the IP it accumulated.
But they rewrote it from scratch. Taking 3 years gap. And the new version was massively buggy with the earlier IP missing.

And you can make another fundamental mistake after reading Netscape story.
When you are in Netscape situation, do refactoring. But are you in the same situation?
1) Better technology is not reason to rewrite. Bad code is not reason to rewrite.
2) Another fancy framework is not reason for rewrite. Do refactoring.
3) Trading for business/operational value against the cost of rewrite. You may not need 3 years to rewrite. In some cases it may be just very less time. (Once I met with email module written badly in one of the product. Every week there was situation to look down and feel insulted when emails goof up with customers. We continued for 6 months like that with choice of to fix than rewrite. When we rewrote the module it took just 1 week for a senior developer.)
4) Paradigms shift in technology every decade. From website to mobile ready website then Mobile App then Platform Integrated e.g. Facebook specific App that open inside FB Mobile App as FB Website then ...
Because you want to meet more customers and they have moved to some different format, you may want to rewrite
5) Security can be a reason for rewrite. Scalability can be a reason for rewrite, because it can change the recipe completely.
6) To fix earlier wrong choice of framework or components or technology stack or wrong design... refactoring will not work alone. Instead consider rewriting specific identified parts of the system.

In last 14 years I met with at least 9 massive rewrites and flipped the business situation to great advantage. Some rewrite took 10 weeks to rebuild a 15 months teamwork while some rewrites took more than 3 years. And in all cases all rewrite cases had same symptom of Netscape earlier but different reason actually. Some of those rewrites were in approval with business people. Those rewrites made business come out of severe risks time to time.
A half dozen more rewrites were simply refused and still suffer same maintainability curse in past 6 or more years. And they did so after knowing Netscape story. Bookish something.
My last mega rewrite was changing an entire system which was coded and value added for 13 years on everyday basis. It took 2 years to rewrite for team of 12 coders, using my another work of 2 years in AI and Java based system developed with another team of 3 coders, as a base line.
Result was complete transformation. Earlier employees were resigning due to too much workload. Company was profitable but was in risk as most old and loyal employees wanting to leave as it badly imbalanced work and home. After new system was in place, employees were happy. Same company could now take up the new opportunities which made it earn highest revenue growth since its existence.

Rewrite is last choice because it is very intense and riskful. Knowing when to use it is critically important.
My word of caution for you:
Business people do not like rewrite because it is throwing away value created. They probably want to kill you for 2 things… 1) there are severe problems open for long and you are not fixing it yet and 2) the plan you propose is “rewrite” to fix most problems.

When business people start influencing technical people often technically wrong decisions are pushed.
One of the killer decision is “To Rewrite Or Not”.
When you are not an expert in the field, and in complete power to influence what decision the experts should take, you often force your beliefs than letting correct decision be made by experts.
Corporate Psychologist often know how to instate balance through designing decision and power structure. Some good managements like Google, FB implement it in better way.
Most code gets rewrite for many reasons. A small portion of code is most long living without any change. Complete rewrite can be a bad idea, but it depends on if you are in a specific situation like Mozilla. has some interesting pointers.

Thursday, July 14, 2016

#1 issue developers should worry

Forcing code to be "reusable", by forcing "configuration" makes it "complex" beyond maintainable and practically useless,

Redundancy is not #1 issue developers should worry, the Complexity is going to ruin everything.

Monday, January 5, 2015

Why software can be so difficult to write for us the humans?

Why software can be so difficult to write for us the humans?
Only software writers will know “Bad software is a bad software”.
Why software can be so difficult to write for us the humans?
Software is system of heavily interconnected dependent nodes, you pull one connection or node and many other will fail. You make one connection right and you will struggle to fix thousand issues. If the interconnections mesh strangled badly, bringing order to it is not a repair or refactoring, it is a brain transplant surgery. It is making B (the mess mesh) to become A (modular order). This like taking an approach where a complexity is squared. In fact with fresh rewrite you can simply build to desired implementation A with steadily improving final desired system.
And we humans have only a limited short term memory. It is just like a scratch pad very very short. Apart from your ability to solve things, the major limitation still is limited short term memory. Which makes it difficult to fit a complex thing in your creative mind while you write code. The way you achieve is think through completely through multiple iterations, revisits to the same core and its part again and again to keep adding to its fabric to make the picture complete in passes…
Greatest ability for any coder is to consider is ability to “deal with complexity”.
Software is inherently complex beyond humans can perceive it completely at once in their little gray matter.
Coding is output in action, of a thorough thinking process, that has answer to, how something will work by implementing it in the code.