======Background and Philosophy======


//Git Winch// did not come up in a vacuum. It was built up over decades, by architect Sabu Francis; an innovative architect from India who wrote his own architecture design software (one of the oldest in the world. See www.teamtad.com )

The basic questions -- which gave birth to //Git Winch// -- that were being asked long time back were: 

  * How do you //organize// an office? 
  * But then, don't organize it so much that the systems you setup becomes //micro-management//? 

Over time, the questions become more sophisticated. Especially after COVID-19, there are questions such as: //Should people work from home? Or hybrid? Or only in office premises?// 

The answer to all this possibly now is better achieved with //Eastern// philosophy such as Indian; rather than //Western// ones. One of the fundamental //principle// in Western culture harks back to the "law of excluded middle" -- where sharp end points are recognized and not anything in between. 

Take most power-point presentations: The audience craves for bullet point explanation. Neat and sharp. With no shades of gray floating in between. This approach bubbled up into many areas -- including software designing; where there is an overuse of forms and overuse of fields on those forms. Much like the overload of bullet-points on presentation.

But the real world, especially when it comes to an individual is quite hazy and scruffy. So most individuals (when you pin them down to extract an honest answer) would really want their own control over the way things are organized for them. Given a choice, they don't want to keep filling up form after form-- they would rather get to the job itself.

The "law of the excluded middle" can even be seen in reductionist philosophy, which is evident in so many software. It is high time we now try an //Indian// way of tying a //lungi// holistically around the waist: The end user is in control. It is not dictated by power-point bullet points or forms with hordes of input-fields or a sharp salesman selling a pair of Western trousers and force you to fit into slots. 

====Lessons from Konkan Railway====

Sabu was the architect for the building and interior works of Konkan Railway Corporation (KRC): One of the toughest and complex railway projects of the world. The KRC team was a very lean //Skunk-works// Just 14 of them. Sabu was the unofficial 15th man. (Kind of like story of the old "The Dirty Dozen" movie) 

One of the important lessons from the way KRC worked is their use of what they called as the "Single File System"  KRC had very flat division of projects into sub-projects. Each sub-project was managed with just ONE  physical "folder". One huge, fat box-folder. ALL documents went into that one box-folder. No desk ever had any file storage for files -- because then there would be a chance the a file may get forgotten inside one of those. Instead all those box-files went into a central file storage. Then if there was a workflow to be followed, the same process repeats with a different officer using the same box-file.

When an officer had to take a decision for a sub-project for some part of it -- say settling a contractor's bills, or approving the architect's drawing... the box-folder was retrieved from the central file storage and plonked on the officer's desk. The box-folder had all the papers received from various agencies for the sub-project arranged chronologically. 

The officer then locates the file relevant for his decision. That paper is flipped over and on the back of the paper (which is usually blank) the officer would write his comments and sign and date that comment. The box-file then  goes back to the central file-storage.

The advantage of such as system is that it was not //reductionist.// The entire holistic of the sub-project are almost completely available in that box-file. If the officer had to search side-ways into other areas before taking a decision. Say the contractor's work was impinging on some conditions of the contract; there is no problem: The officer can shuffle thru the file and get the contract documents there itself. 

There was another major advantage of this system. This speeded up work enormously. Why? Because if some other officer would want the same box-folder at the same time, he would not get it because the earlier officer was working on it. The box-file was "locked" so to speak. Which meant that each officer had to dispose off the work as quickly as possible and return the box-file back to the central file repository. If the work was lackadaisical, there would be angry glances from other officers around!

Those 14 people were one smoothly working, well-oiled holistic team -- working always with a complete picture of what was going on. 

When you work with //Git Winch// you would notice you can see shades of why some features were implemented the way they have been.  And why is that //Git Winch// has such minimal features. But it can make an enormous difference in the way people and data are handled. 

What Konkan Railway achieved with physical box files — clarity, completeness, and speed — Git Winch brings to the digital workspace. No scattered forms or hidden data; the whole story is available to those who need it, when they need it. At the same time, it does //not disrespect Western approach either!// 

You can "divide-and-conquer" and setup separate repositories for sub-groups to work on a need-to-know basis.

Git Winch isn't just another tool — it's an invitation to rethink how your team works: holistically, humanely, and without clutter. I hope you enjoy discovering this difference.