karlkfi's comments

It doesn't actually matter what story points stand for, as long as they converge towards a metric that can be used for consistent predictions.

In fact, if you pin them to something concrete, you lose the ability to adjust the point value to account for less-concrete variability.

They're almost always "pointless" in the beginning, no better than a Super Wild Ass Guess (SWAG). But if you use them relatively consistently over time, have relatively consistent work, and account for team size changes, they can become valuable tools for predicting completion time of complex/complicated tasks/project.

> Connected cars are already on the road, using lidar & radar, not the phone network. Xu points out, “even today we have the technology that can support autonomous driving”.

This point is silly.

Lidar and radar don't replace high bandwidth internet on a self-driving car. The beefy super computer in the trunk is trying to replace the cloud compute processing that is inaccessible because there's not enough low latency, reliable bandwidth available to stream a dozen camera, lidar, radar, and IR feeds over the internet for remote processing.

Self driving right now requires either precision 3D mapping and local processing of a huge amount of data from multiple sources OR highway-only limitations where there are fewer objects to track that all move in predictable ways. Both of these would be easier and produce better results with more bandwidth and lower latency.

5G may not be mature enough to make a difference today, but that doesn't mean connected and self-driving cars aren't a legitimate use case for the technology and its stated goals.

DC/OS (A Mesos distribution) can be used on your laptop with dcos-vagrant or dcos-docker:

- https://github.com/dcos/dcos-vagrant

- https://github.com/dcos/dcos-docker

However, your point is somewhat valid in that Mesos requires you to allocate resources to everything you run, while resource allocation/enforcement is optional in Kubernetes. So you can easily run too many things and freeze your computer with Kubernetes, while Mesos is more conservative.

Agreed. Autoscroll breaks the mobile experience horribly. Small text... No pinch to zoom... Half the text is always off the screen in landscape...

It's worth noting that Kubernetes can also run on top of Mesos (https://github.com/GoogleCloudPlatform/kubernetes/tree/maste...) and DCOS (https://mesosphere.com/learn/).

So if you invest in Kubernetes and later want to take advantage of Mesos you can lift up k8s and put Mesos underneath.

Mesos is definitely more mature, and you can use Marathon for container orchestration, which is a little more mature than Kubernetes, but it's also a bit simpler. Marathon doesn't have the service, secrets, or pod abstractions, for example.

DCOS adds some additional benefits on top of Mesos, like the dcos-ui and dcos-cli. One of the more compelling features is one-step cluster package installation (ex: dcos package install kubernetes). Currently, the community edition is available on AWS (https://mesosphere.com/amazon/).

I do agree that the kube-up scripts in k8s are a bit of a mess. There's really hard to read and reverse engineer, and each provider has their own divergent deployment methods. That's one of the things DCOS is trying to standardize, to have a consistent deployment pattern for Mesos frameworks that deploys their core components inside Marathon, giving them a more battle-tested platform to live within, and granting automatic resurrection in case of failure.

YARN (Myriad), Spark, Kubernetes, Marathon, Swarm, and Aurora already run on Mesos, with varying degrees of maturity.

As you say, the primary benefit is that you can provision a single Mesos cluster and share its resources across various frameworks.

IME, it's immature. It's usable, but not awesome, and not as feature-full as Jenkins.

It's one killer feature is pipelines, but the hierarchy is fixed depth and hard to learn. Every other level is exclusively either parallel or sequential. Just like Jenkins & Teamcity, it's best to run every step in a container, but this is something you have to manage yourself.

Another major drawback is that the config is all one giant xml file. The GUI makes it a little easier to use, if you can figure out how to navigte it, but when things get hard you end up editing the global xml by hand with the possibility of accidentally breaking the config for the entire cluster.

The only CI I've seen with native container isolation AND pipelines is http://concourse.ci/ But it's a one man show at this point, even more immature than GoCD.

Travis is poor man's CI. It doesn't scale well, even if you pay for it. And it's not customization enough to use for anything except unit tests and maybe integration tests if they're small and fast.

Never used Hudson.

TeamCity seems about on par with Jenkins.

Well, for one thing, looking at the screenshots and game description leaves me with no desire to play it... This kind of "advertisement" also makes me feel like I did you a favor copying/pasting the link to look at it. You need to give people who have already clicked the link a reason to pay $3.

After going the extra mile to then click on your facebook link, scrolling down to find the link to a video (the into story video), it now seems apparent that the production value for this game is really low. Almost static screen with an old guy's mouth flapping up and down and text coming out? Boring! Text that leaks out of the thought balloon? Amateur!

Sorry if that was harsh, but I'll pass.

One of management's jobs is to enable and empower the workers. One of the principals that enables Kanban development is that management should not dictate worker process. If management doesn't know that they may be tempted to fix the development problems with more process, which actually disempowers the workers. Adding more dictated process may work in the short term, but it's a tactical fix, not a strategic one. A well run business keeps tactics and strategy in balance, and hopefully delegates the tactics as low as possible, to retain empowerment. Good management acts as a multiplier to worker productivity. Bad management cripples what it's trying to manage.

So yes, you need good management, but good management alone does not guarantee success. Management cannot be the source of the solution to every problem.

The other bit to take into account is that management can benefit just as much from its own cycle of metrics, feedback and retrospective action. All levels of an organization need to be able to improve, not just the developer teams. However, that's usually a completely different set of tools and skill sets.

http://www.amazon.com/Kanban-ebook/dp/B0057H2M70/ Note the subtitle: Successful Evolutionary Change. Don't try to change everything all in one go.

And if you already know Scrum, here's some differences: http://www.infoq.com/news/2009/05/kniberg-kanban-v-scrum

The real silver bullet behind Kanban has nothing to do with Kanban. It's the desire for continual improvement and willingness to start where you are and improve from there.

Anytime you attempt to make a huge process shift you are tempting fate and risking failure. The short term drawbacks to huge change can often stifle the process before it reaches maturity. The trick is to work through the rationalization with the team based on current observable problems and lead them towards self-realization and analysis of their own problems.

Most people have ideas of how to make things better, but if you lead them towards the desire for slack, optimizing for the bottleneck, rather than maxing out everyone as if they're all the bottleneck, then you can easily get from there to Kanban-like WIP limits. From there you can adopt other solutions as the problems they tackle are realized.

Smart people frequently arrive at similar approaches whenf aced with the same problems, but not always. Your team may find some novel approach that works better for your context, or they may go looking for options and find Kanban. But the goal should begin with being able to communicate process problems, ask how they can be improved, test the potential solutions, and adopt the best ones.

Unfortunately, the biggest hinderance to gradual process improvement (once your team is on board) is that software tools tend to offer a "whole solution" and don't have the ability to grow with your team's maturity, unless they're writing it themselves.

If this is a all it takes to be in a "death spiral" then we're way past the event horizon and in a vertical free-fall.

Call me when your hiring process is brain dead, there's no management training, 6 month reviews are tied to bonuses, governance only happens yearly, "phase two" is the punchline of the never ending joke of quality, and 60%+ of the engineers are contractors...

The only owners who would say no are the ones who started a company because it was the only way to make their product come to life. They treat the product and the company that forms around it like their baby.

Most owners are entrepreneurs or businessmen or visionaries who are in it because they enjoy(ed) the process and would gladly start over with a new project with a huge slush fund to fall back on or escape the stress and responsibility of the start-up world all together.