I've recently been reading "The Lean Startup" by Eric Ries. It has a
bunch of really interesting ideas that make a ton of sense to me. [I'm
not done but it really seems excellent]
It's important (especially when resources are tight) to do the right
things - not just to do things efficiently. Making good time going the
wrong way isn't very helpful.
Looking back at the Linux-HA (now Pacemaker) project - we kind of just
did what seemed right to us to do. Some of it was really right - and
some was not. It is /far/ more capability than most folks need - and
*/*far*/* more complexity than it likely merited.
As a result it took the team over 5 years to get the code from release 2
(aka Pacemaker) to work well. That's VERY long time. And in the end,
few people could understand how to use it - at least not until Dejan
invented the CRM shell. That's one of the things that worked out very well.
But we wasted years and tons of time building what was probably the
wrong thing. I'd like to avoid that.
Ries defines a startup as "*an organization dedicated to creating
something new under conditions of extreme uncertainty".*
By that definition, this project is a startup. We're trying to create
something new (check!) under conditions of extreme
uncertainty(double-check!). Why extreme uncertainty? No one has ever
tried to create a single product to do the kind of thing we're trying to
do in the way we're trying to do it. We don't know who all might
benefit from the discovery data, we don't know how to present it to them
in a way that really helps them (whoever they are). In general, we
don't know who all the right customers for this product are, nor what it
should do. We don't know how many people will be interested in
contributing to it. That translates to extreme uncertainty to me.
One of my favorite ideas from the Lean Startup is that you need
validated learning to deal with this uncertainty. Open source provides
a unique form of learning - because you talk directly to (some of) your
customers. But it isn't validated learning. Validated learning says
that you know you did the right thing /because it changed the behavior
of your customers/.
A feature doesn't do anyone any good unless it changes people's
behaviors. Surveys of customer satisfaction are great and all, but
knowing what people are doing - and how our changes affect them - that's
a much more validated learning. It's far more useful for making
decisions on what to do, and what to do next. It's easy in a survey to
influence the outcome by what questions you ask and how you ask them -
even if you didn't mean to.
So, I'd like to add two unusual aspects to our project:
One is to collect measurements of how people are using the software,
and collect that data on an
opt-out basis. I understand that it needs to be clearly spelled
out, and what data we've
collected needs to be non-confidential, and masked to make it
impossible (or very difficult)
to figure out anything that might be sensitive - and it needs to be
opt-out, and logged
exactly what data was retrieved.
The second is to classify features as core or non-core. Core
features are those that have been
validated as being useful - by seeing that they're helpful --
through the metrics. Non-core
features are those that haven't been validated through metrics as
providing positive changes
in customer behavior. Either they haven't been measured properly
yet, or they were measured
and didn't "measure up". In an ideal world, we'd like a software
architecture where
non-core features can be removed in the future if they don't
"measure up"
after being tested. Features which no one uses add complexity and
maintenance effort.
But you need to *know* which is which.
Another related idea is that every startup (or project) has a number of
"Leap of Faith" assumptions that are key - but you don't know the answer
to. So, you need to test those assumptions. Some you can test through
code, and some don't require code to validate. I've been thinking about
a few of those questions. Here are some first blush assumptions/questions:
- we will be allowed to require agents on every machine
- we will be allowed to have our agents communicate with each other
- we will be allowed to have our agents monitor the resources on the
machines they're on
- people will be willing to augment or replace their existing
systems with this code
- will people need to purchase support for this to be viable in
their organizations
and so on...
What are your thoughts or reactions to this?
If it doesn't seem clear, then we talk about it -- or you can read Ries'
book and we can talk about it after that...
--
Alan Robertson <[email protected]> - @OSSAlanR
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
