WebSockets are a tool like any other and as usual, picking the wrong tool for the job is a great way to shoot yourself in the foot. Agree with the author that they aren't suited to replace HTTP but I don't see the need for this apocalyptic tone. WebSockets have been available in many tech stacks for a while now and we don't see much abuse. Developers disciplined enough to stick to Rails don't seem overly prone to jump on the new shiny toy without thinking.
Web Sockets are great to bring some of the more heavy duty apps from Desktop/TCP to the web. PubNub, Pusher and the likes show it is possible to achieve reasonable scale.
#NoEstimates to me is often an indicator of poor company culture. It immediately makes me think of shops where there's a disconnect between developers and the rest of the organization.
The business and product people are unable to explain why they need estimates. Often they don't know it themselves and are just passing on the request from their bosses or customers. They hold devs accountable for estimates even if the requirements, priorities and teams change. They also think estimating is free - they don't realise that producing meaningful estimates takes time and requires a deep understanding of the code base. It also requires clear, precise requirements which they are unable to provide.
Developers at these shops believe their single responsibility is producing elegant code. They don't have to prioritise features based on their cost and value; and they don't have to communicate with clients, investors or sponsors. Many devs never learned estimating, that's why they call it an "art". They spend forever to produce estimates that turn out to be way off, even if requirements and circumstances don't change. The lazy way out is to say: Estimating is a waste of time because estimates are almost always wrong.
I have seen estimating done right: It took about 5%-10% of the overall effort spent. It helped make or break business cases, prioritise features and manage client expecations. It raised questions that, if left unanswered, could have resulted in massive cost explosions and unhappy customers later on.
Key cultural ingredients:
- Business and product people don't live on an island. They understand that estimating is neither free nor instant. They work close enough with developers to know what level of detail is necessary and they also understand the value of refactoring, test automation, pair programming, etc.
- Developers don't live on an island. They are involved in product decisions and client communication, so they understand why people are asking for estimates. They not only take pride in the quality of their code but also in their ability to deliver features quickly
- Estimates are not used to crucify developers, but the company culture allows an open and forward-looking conversation when the actual effort deviates a lot
- Estimating is seen as a skill. Becoming good at it (ie. accurate and efficient) is a requirement to get senior dev roles
- Everybody understands that when the world around them changes, the estimates change too
Final note: work should be estimated in line with the predictability of the business. If your company is pivoting every 8 weeks then there's no use in estimating 6 months out. If you have a successful app for iOS and consider expanding to other platforms, it's probably worth estimating
Web Sockets are great to bring some of the more heavy duty apps from Desktop/TCP to the web. PubNub, Pusher and the likes show it is possible to achieve reasonable scale.