Kaizen and Kanban

Kaizen and Kanban are one of my favorite philosophies around process-control. I enjoyed reading abt it a lot in College. it had a profound impact on me and continues to inspire me even today. It was taught as an elective that I opted for and while others in my class (Computer science) didnt like it as much, I was drawn to the core principles behind it. The more I thought abt, the more I appreciated it…

Kai – change , zen – good
Kaizen means continous improvement – to do it better, even if its already good.


Kan – visual, ban – card
Kanban – kinda “Just-in-time” delivery. A system based on “demand-driven” production cycle.

Keeping it simple isnt so simple, uh?

This is about dealing with complexity in Design – in software and elsewhere.
I wonder at times why we start off with a complex design and as time goes by we spend more time trying to simplify it. We give it several names, for instance in software we call it ver 2.0 ! In hardware, we may add a suffix like “turbo-charged something” or a “power-something” or simply “something plus”. For instance, they now sell “Tylenol-plus”. Now dont you feel like an idiot having bought plain-old tylenol all these years? Are we duds? Dont you think the guys had brains to add the plus-stuff right from the beginning?

Take the age-old Java versus C++ battles. Paraphrased a quote from a book that I read several years ago when I was still doing JDK 1.2 – “Java makes OOP simple by taking out complexity out of C++ like multiple inheritance, pointers , templates , etc. ”

Somebody down the line realized that templates are not so bad…So they introduced it in Java and gave it a rather synonomous name “Generics”. So who are we to beleive? The original designers and architects of Java who taught us that generics are not a good thing or the geeks that now tell us well, languages evolve to suit the need of developers and you should change your ways as well.

Now somebody pray tell me that it took only the founders at Google to create a search engine with a single text-box. Then started the culture of a “simple and intuitive” interface. Why is it so tough for our brains to create something simple?

I am not talking of iphone that took touchscreen technology to new heights. Maybe sometimes it just takes technology to become cheap and widely available to adapt it to real-world applications. But I hate it when we have the technology at hand, but fail to realize its potential.

Take another instance, when people who wrote simple Java classes were mocked condescendingly by the “geniuses” in the elite group that worked with EJB 1.x…It took a fancy name like POJO for it to dawn on us that simple Java classes with a public no-arg constructor with getters and setters are the next-big thing. Huh?

Tell me something- Spring versus EJB. Its common knowledge that the former is simple and suits almost all requirements that EJB was designed to meet. Spring doesnt use any new language or technology that was not known at the time EJB was written. Why couldnt EJB authors think the way Spring designers did?

Are we conditioned to think complex that kind of hinders us from “keeping it simple, stupid”?

How often have you not heard some sales guy telling you that the product has become a lot “simpler to use”? Are you kidding me? If nothing changed between now and a year before, why did you create something that was “not simple” an year ago?

Keeping it simple isnt so simple, uh?

JSF References

JSF Central
Java Server Faces Developer
Sun Java Server Faces
Java Server Faces Tutorial
JSF Specification

Windows Cloud

Azure Platform
Introducing Windows Azure
What does Windows Azure mean for Developers?
Developing Java with Azure

QoS Parameters

TechNet Link – simple and lucid

QoS Parameters
Different applications have different requirements regarding the handling of their traffic in the network. Applications generate traffic at varying rates and generally require that the network be able to carry traffic at the rate at which they generate it. In addition, applications are more or less tolerant of traffic delays in the network and of variation in traffic delay. Certain applications can tolerate some degree of traffic loss while others cannot. These requirements are expressed using the following QoS-related parameters:
• Bandwidth – the rate at which an application’s traffic must be carried by the network
• Latency – the delay that an application can tolerate in delivering a packet of data
• Jitter – the variation in latency
• Loss – the percentage of lost data

Java Annotations

Useful links on Java annotations – With the proliferation of annotations in all new frameworks and toolkits, its imperative that Java developers understand the basics and roots of annotations –

1. Sun link
2. Javabeat
3. More info
4. Oracle link
5. Introduction

Definitions of precipitation