Bloglines alternative
Well now that Ask.com finally pulled the plug on Bloglines I am in need of an online RSS reader.
I do know about Google Reader but I’ve never grown fond of it.
I did find FeedShow so I guess I’ll have to give that a try.
Update 12/9: Found this list of feed aggregators: http://www.newsonfeeds.com/faq/aggregators
If you know of any other online feed reader please let me know. I might even consider hosting it by myself if I find an open source one that is nice to use.
Other search terms:
- bloglines alternative
- boglines alternative
pifts.exe
I just read about pifts.exe at a fellow Swedish blogger.
It does look a little suspicious, but I am not convinced it is a cover up.
All the threads I have seen mentioning pifts.exe at the Norton Forum site, before being deleted, has contained loads of junk.
I might be a social attack against Norton.
Coding is fun
… and so is solving problems using software.
Consolidating documentation and writing for the sake of wasting bits is utterly boring.
I have a hard time writing for an audience that I know will not take the time to understand what I write if I make it unambiguous. But most of the time they will make weird assumptions if there is a tiny hint of ambiguity.
I can totally understand that not all people grok software development, but I’ve always thought logical thinking was the killer feature of mankind. Recent encounters makes me wonder though.
This also leads to the importance of a well defined vocabulary. I waste huge amounts of commas and parentheses when writing systems related documentation because I can not allow myself to make any assumptions at all about the readers current knowledge and taste in words.
So I guess it’s my fear of ambiguity that makes my writing unreadable. At least I’m not spreading any misinformation 
…and while I’m writing about my writing: My sentences are way to long and I don’t know if it’s OK to start one with ‘But’ just to skip a comma in the previous one.
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.
Other search terms:
- research: cohesion prefixes
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?
Other search terms:
- information vs knowledge
