I came across a version this on Quora today. Googled for the source and ran into this post.
When the top level guys look down they see only shit; when the bottom level guys look up they see only a**holes. (Apologies for the unparliamentary language, I did not want to dilute the emotions ).
Ron Jeffries has an excellent write up on estimation on the Pragmatic Programmer website
On Big Bang rewrites
The C3 project’s purpose was to replace the entire family of Chrysler payroll programs. It didn’t accomplish that. Many years later, the subsequent project to replace the entire family of payroll programs has also not accomplished it. We now realize what should have been done.
We should have replaced the broken bits, one at a time, most valuable first.
The fundamental idea of making a complete list of everything payroll, and clicking through it, was wrong.
It seems that “they” often want to know how long something is going to take, and how much it will cost. My view is that “they” don’t even know what they want, so we bloody well can’t possibly know how long it will take. However, “they” are often powerful and have the money we need, so we need to answer their question, even though we cannot.
Most of the time, “they” know how many people they’ll give us, and how much time. They do that head-shaking thing until we “estimate” the numbers they have in mind. So we should turn the question around. “How much did you want to spend, and when did you hope to see the product?” Then they tell us, and we decide whether we can do something reasonable within that budget. If we can, we go ahead. If not, we politely decline the business.
On vague product ideas
If no one knows, and no one has an idea, odds are the project is too vague and too big. Run away. However, if for some reason you enjoy leaping off cliffs hoping to generate a plan on the way down, here’s something to try. Chet Hendrickson and I call it the “Five Card Method.”
I recently watched Shawn Achor’s TEDx Video on Happiness Advantage / Positive Psychology.
It was funny, interesting and inspiring. Do not miss it, Highly recommended.
Wish you all and your family a happy and prosperous year ahead.
May all your wishes come true.
You need to communicate with the server to retrieve the model from the server, and to put the updates to the model on the server. These libraries typically should provide a higher level of abstraction than xhr (or even $.ajax). Typically they should handle
- The model serialization / de-serialization (ex: date format issues). Most of the community as settled on JSON as the default format here.
- Protocol used to communicate with the server (REST / DDP – See below)
- Provide a higher level of abstraction to deal with asynchronous ajax calls like jQuery’s Deferred / Promise abstraction.
- Change tracking?
- Isolate and abstract the server communication from the rest of the application modules.
In the Requirement Specific Parameters post I talked about live / real-time updates. Meteor implements real-time updates on top of a protocol called Distributed Data Protocol (DDP). This alleviates us from a need to poll the server for updates. Other frameworks like Derby also support this real-time updates, they call it Subscriptions. I am hoping in the future everyone will settle on a standard protocol.