The Long Tail and The Diamond Age
I’m almost done reading The Long Tail
It is the kind of book where I feel I’ve thought of the basic ideas presented before. Not that I could have written it myself though. Far from. Chris describes the long tail as all the small niches that doesn’t get any shelf space at Best Buy, but are very lucrative when exposed on the web. This is because web sites like Goggle and iTunes helps bringing niche consumers and niche producers together. It also looks like more and more people are turning away from being hit consumers when it becomes easier to find just the right niche products.
Anyway; this infinite range of products got me thinking about The Diamond Age
On Baking requirements
Jeffrey Palermo states in his post ‘Baking requirements – Developing with raw ingredients is waste‘ that requirements has to be thought through before they are presented to the developers.
I think that is a statement that holds true for all levels of requirements. Software development is intangible and it is perceived that changes are easy to do. This leads to bad requirements from everyone. Customers doesn’t think through their needs and expectations before starting software projects. Business designers doesn’t think through either requirements or business rules enough before presenting them.
Very often it is possible to start working on a requirement even though the related business rules aren’t clear. But most times I find the business peoples lack of understanding of the constraints we developers are under to be very frustrating. A rule that is easily implemented or discarded in a manual process might need architectural changes in an automated process. It is frustrating for both parties. The current buzz is that developers should reduce the gap to business, but I think the responsibility to close that gap falls equally much on the business people.
We could argue that learning to program is hard, but failing to learn programming would also be a lesson learned.
Cohesion and redundancy
We’re doing some static analysis with NDepend as part of our daily build and the cohesion measurement caught my interest.
When googling for cohesion I stumbled upon some articles discussing reading and writing normal text (normal in this case meaning not source code).
The concepts that I fell for are cohesion and redundancy.
Here is what Wikipedia has to say about these words regarding programming:
- Cohesion: a measure of how well the lines of source code within a module work together to provide a specific piece of functionality.
- Redundancy: The notion of unnecessary, dead or duplicate, code.
… and here are the same words regarding linguistics:
- Cohesion: the linguistic elements that make a discourse semantically coherent.
- Redundancy: In language, redundancy is the use of duplicative, unnecessary or useless wording.
Linguistics also has the notion of coherence; what makes a text semantically meaningful.
In this article Alice Horning discusses research about cohesion and redundancy in writing. It made me draw some parallels between writing good literature and writing good source code.
Alice states that novice writers lack the ability to distance themselves from the writing to see their text from a readers point of view. I see the same pattern on and on when reading, and trying to understand, source code. It is, mostly, not the programmers’ lack of technical competence that makes it hard to understand their intent. It is their style of naming and grouping things together that creates a total lack of linguistic cohesion, and coherence.
I guess Domain Driven Development would tend to some of this but all I know about that is what Jimmy Nilsson said on DotNetRocks. At least a common way of naming, abstracting and grouping things within an application would use the linguistic sense of redundancy to make code more understandable. Design
patterns will also use redundancy to help the reader understand code since he probably will have a good idea of what’s coming if the code corresponds to a known pattern.
Code reviews also help a lot, but that is done far less than one would like.
I think the cure for this is to take time to read more code. Just as you need to read lots of literature to be a good author you need to read other peoples source code to enhance your own skills. You need to read code that is more than just samples and proof of concepts, and I think it should be code that you are not emotionally attached to. So get your favorite open source application and read its code. While you’re at it you can contribute to it and make the world an even better place.
Discoverability and findability
I’ve been hearing, reading and thinking a bit about discoverability lately.
This essay sums it pretty well. He goes into some discussion about limiting the choices by prioritizing different features and making basic decisions for the user. Like making the stearing wheel more discoverable than the fuse box.
I think that making these decisions are not only about usability they are really the decisions that differentiates you from your competition.
You can have one million features but in the end it is your default feature set that identifies your product. If you decide to turn all those little design decisions into options for the user your product will either be identified as the power users dream or an unfocused mess.
Since you only get one shot at the first impression it’s a tough choice for a small shop. Should you aim at the small population that likes your way of solving the specific problem or should you aim at the small population of users that will really investigate your product and tweak it to their liking?
If you’re selling to ‘ordinary’ consumers my guess is that there are more people who will like to have a guided experience than there are curious explorers. The curious explorers are probably divided in two camps; The backpackers who want lots of low cost choices, and the expeditioners who will pay whatever it costs if it gets them where they want.
Information vs knowledge
I was at an architect event at Microsoft today called ‘The Social Life of Information’ where Beat Schwegler built the foundation for a day of Share Point demoing by talking about information vs knowledge.
The rest of the day was ok, but I got stuck thinking about knowledge.
I think that our industry would benefit a lot if we could refine (or maybe even redefine) the ways in which we transfer knowledge. If we had the tools and culture to transfer knowledge the success rate of IT projects would go through the roof.
We need to stop transfer vast amounts of non understandable information.
I think that a great tool for moving massive amounts of information into the knowledge realm is a wiki. Every development team should have access to an unrestricted wiki. If management can’t handle the thought of having it’s staff writing without moderation something is wrong in the organization. Something is also wrong in the team if the unmoderated writing turns into flame wars and bullying. It is totally ok to restrict outsiders, even deny them, but let the team be free. Every new developer should get time to be familiar with the wiki, maybe even before looking at any code.
It is not enough to use the wiki to cross reference all the information about the current state, we also need to write down the discussions and mishaps that lead here. That way we can turn these vast amounts of information into knowledge that is transferable.
I really hope that knowledge sharing gets the same status as object oriented design, unit testing and so on.
…but maybe that is what has been happening lately with the rising of architects in this industry.
It should be the role of the architect to spread knowledge inside his organization and to absorb knowledge from the community of other architects. He should also create an environment where all team members and stakeholders can share their thoughts (especially the unfinished and unpolished ones) without feeling stupid or elitistic. If we can get people to collaborate around unfinished ideas we will make wonders.
It is well known that the earlier you find a bug the less time it takes fix it.
What if we could find problem areas even before they have turned in to a concrete idea?
