Just funny? Or also true?

Found via Geek&Poke.

Found via Geek&Poke.

One concept which goes with almost all discussions of PaaS (Platform-as-a-Service) is the  application marketplace or app store.

The Promise…

The argument hype goes something like this: If you specify an platform standard, get more than one hoster to host it and finally convince people to develop little applications (or widgets) for it, everyone wins:

• the hoster can leverage its existing customer base including the possibility of cross-sells
• the application developer can sell his app leveraging the combined numbers of customers of all participating hosters
• the customer having access to a huge selection of apps able to be integrated into his homepage

etc.

Reality sets in

Besides technical and cooperational problems the equation bases on the assumption that you get a lot of small or medium sized ISVs (Independent Software Vendors) to program against your platform specification. If you are aiming for business developers this means there has to be enough money in there for them to lock into the platform constraints. The promise now is that electronic marketplaces lower the barrier of entry for these developers enough to ensure profit for all.

Promise? Maybe you’ll say »Hey, I know this works! What about Apples app store?« Exactly my first thoughts but let’s look at the numbers provided in a recent blog post of an developer who has to know:

According to the developer of Zen Jar which ranked around position #30 when the article was written he earns as much as……20$ a day with his app. Considering that there are currently over 36.000 applications to choose from I personally had expected much more profit from entering the Top 50 in a popular category.

What are the reasons for this? For one it’s the standard pricing of .99$. To become really rich at this price you have to sell a lot. Looking at the numbers in the article at position #34 you can expect 30-35 downloads a day. If this is not enough for you you have to do marketing which cuts your profit even further.

As also is mentioned in the article this doesn’t mean the business model is wrong. It just shows that app stores aren’t the 1, 2, 3, PROFIT guarantee as some people suggest. There are still some problems to make the model work as »advertised«.

So what?

Just providing a platform to develop and run applications on is not enough. Providing a place to list this apps and provide services for licensing and billing is not enough, either. What is often missing in the discussion of the »application marketplace« is how to aid developers in marketing their product. If you leave the myriads of »little« business oriented developers alone with this task they won’t have enough resources to do it on their own and still be profitable enough.

One more challenge to overcome in the PaaS opportunity…

I stumbled upon a blog entry from Jeff Langr today in which he challenges the concept of »chickens and pigs« in agile development.

His line of reasoning: Having a rule which forbids communication is not agile at all. He suggests to sustitute an other agile value instead: courage. Simply ask people who are not helping in the daily to stop. And talk about it.

You can read his full view here.

I like his suggestion for dealing with chicken-rule-fetishists:

The next time someone calls you a chicken, let them know that there is a new animal in agile. It’s the ass. The ass is the person who dictates how things must be. They are stubborn, controlling animals. Perhaps the best thing to do with an ass is to give it a good swift kick.

I think Jeff has a valid point there. Nothing is more tedious than being constantly remembered by a Scrummaster(tm) that something »isn’t following the Scrum rule book«. On the other hand these rules are necessary scaffolding for beginning project managers without a lot of experience under their belt. Maybe the truth is somewherein  between again. If you need this rule, use it. But get rid of it as soon as possible.

What do you think of this rule? Do you use it?

[This article is a rerun from the old blog. Because the matter is still interesting (to us) we migrated and republished it.]

Today I want to answer a question which I  pondered about for quite a long time:

»What does lightweight really mean?  Does it mean anything at all?«

What annoyed me most was that everyone nowadays seems eager to point out (MULTIPLE TIMES AND IN CAPS) how lightweight his process or framework or whatever is supposed to be. The fact that no one seems to gloat over the fact how »heavyweight« their product is arose the suspicion in me that the whole heavy- vs.  lightweight comparison is more a marketing- or coolness thingy than something helpful to dispute or even base decisions and strategies on.

I deliberately used past tense in the last paragraph because thanks to Lu Kim Man and Keith Chan these times of doubt are finally over for me! In their book »Software Development Rhythms«  these guys give a definition of »lightweight« even  I can understand an use:

The weightiness of software processes and practices is a matter of the values that arise from them and the degree to which activities directly benefit and contribute to core developers (i.e., people) and core software programming (i.e., products). [...] For example, a software process that requires writing all-embracing design documentation for commercial database applications may be considered heavyweight as it does not directly create value for the core development.

They further state:

Heavyweight processes have their place. In this case, detailed documents come in handy when we are going to outsource technical support and software maintenance abroad.

This finally makes the term a useful tool to use in discussions and for decision making. The meaning is clear and the trade-off between the extreme opposites can be assessed and evaluated in concrete contexts.

For those wondering: The emphasis of people and product in the quotation refers to the agile mantra »People over Processes, Working Code (=product) over Documentation. Seen this way one could reason that »the more lightweight you do the more agile you are (little padawan)« but this is a job for the evangelists out there which I don’t want to awake with my humble shenanigans. If you are interested in my opinion: It’s BS.

Let’s summarize:

• The weight of a tool or process can be defined as: »How directly do developers and programming tasks benefit from it?«  In other words: If the answer to »Does it speed up development in the short term?«  is Yes we are on the lightweight track.
• Sometimes we sacrifice short term benefits in favour of long term, project overarching goals. By doing this we enter the heavyweight realm.
• There is place for both strategies. Neither one is evil.

Amen.

Can you live with this definition? How do you define »lightweight«?

I just discovered the works of John Gall and I LOVE IT!

Just two quotes for now:

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
—John Gall

and

Complex systems tend to produce complex responses (not solutions) to problems.
—John Gall

Wonderful.

Lets begin this post with a rant: I really really hate it if people try to turn agile principles against the customer. The mission: Mask laziness by gaming the system.

The sort of situations I talk about look like this:

A: »Do we have to refactor this code? It’s really ugly and may or may not break somewhere in the future.«
Variant 1:
B: »Don’t bother with this, the Product Owner didn’t say anything about quality.«
Variant 2:
B: »Let’s ask the PO! PO, what is better quality worth to you? Prioritize! You can have more features or quality for the ones we already implemented.«

Oh yeah?  It’s unfair and plain nonsense. Don’t get me wrong here: There are cases where bargaining over different qualities of service (QoS) has its right and is essential. But most of the time it hasn’t and isn’t. Especially if the code implemented is brand-new.

In all agile methodologies I know you promise the PO to deliver a baseline of quality from the start. It should be clear that »just getting things done« in guerilla combat mode is not enough. As a member of an agile team I implicitely promise to do things like e.g.:

• Planning the architecture
• Weighing my options
• Communicate
• Deliver the best code I can
• Test it
• …

without asking the customer every time: »What is it worth to you?«. Cope with it: If you don’t consider this activities as included and mandatory a priori you are not an exceptional doer churning out code like the Chuck Norris of development. You are just lazy.

From the perspective of the customer this behavior looks like an eternal loop of terror:

1. Deliver crap.
2. Whine over how you need a whole full-time month to remove technical debt.
3. GOTO 1

The Manifesto for Software Craftmanship explicitely addresses this by postulating to commit to the following principles:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration,but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.

Bravo. Software should be seen as a craft. Get over it: Every time we deliver crappy code and apologize with »I had no time to plan!«, »The PO didn’t want quality!«, »You wanted results: you got it!«, we already lost the cooperative game. Why? Because of two things:

1. What the PO asks you to do is to implement her ideas as simple as possible (YAGNI, KISS) but not simpler. What this minimal effort looks like is up to you and can only be judged by you. The PO can’t know this!
2. If there really is a trade-off between time and quality we should have presented the PO the options beforehand. If she doesn’t seem to care: just don’t commit to it! It’s all  about nuts-in-advance versus whining-after.

FTW: Yes I’m an craftsman, too.

If you are interested in more views on the topic be sure to check out this InfoQ article.