Conscious Development

AKVA club of HETKY organized a seminar about agile, scrum and testing. It was a two-day cruise from Helsinki to Stockholm and back and there were many speakers from different backgrounds. There was a common (though unplanned) theme – doing agile is not easy. Read the rest of this entry »

A while ago I attended an evening organized by Tietotoviikko. They had a few presentations and an ending panel discussion having members from both client and supplier side and also a researcher.
The topics of discussion were IT-suppliers ability to keep their promises, customers’ expectations towards their suppliers and what makes real partnership.
Read the rest of this entry »

Today’s software development is more challenging than ever. Yes, in some part it’s a lot easier with higher generation tools compared to assembly languages, but I claim that requirements have raised even faster than the abstraction level in tooling. Read the rest of this entry »

I previously had three different WordPress installations, and it got a maintenance headache (although upgrades are relatively easy on current WP) and I din’t like fact that I had three different accounts, had to install plugins thrice etc.
Luckily, there’s an edition of WP that allows me to have multiple blog instances on one installation, namely WordPress µ. I already had a MU up and running (in /mu/-directory), so let’s go importing the pages, posts and comments from old WP’s. And it was… well…almost easy. Read the rest of this entry »

My old WP got hacked, and this post got deleted. Basically, all I said can be founf from Jouni’s post.

This post also got deleted. Basically, it was an announcement that there already numerous comparison between different cloud vendors and their prices, like here and here.

In the process of implementing server-side validation for an ASP.NET MVC project using great xVal library, I found an interesting..err.. dare I say bug in the .NET framework. I used xVal and dataannotations on Linq2SQL objects, pretty much following the guidance here. Of course, I wanted the error messages localized and luckily, the ValidationAttributes have properties called ErrorMessageResourceName and ErrorMessageResourceType so it shouldn’t be a problem.

Following eXtreme Programming principles, I wanted first to have it work doing the simplest possible solution. Just add a plain required attribute and test. Voilá, it works! Great, so let’s add the localization in place. I added the attribute properties and suddenly the validation didn’t work anymore. Why is that? After close examination with debugger and Reflector I found that:

• According to reflector the attributes are there and their properties are correctly set
• According to VS debuggerTypeDescriptor.GetProperties(myModelObject).Cast().ToList()[0].Attributes doesn’t contain the RequiredAttribute!

That’s interesting. No exceptions were raised, no error messages were given. The attribute was plain missing and thus validation didn’t work.

OK, let’s try it another way. Inspect the object using ordinary reflection methods using the following code:

foreach (var pi in instance.GetType().GetProperties())
{
 Console.WriteLine(“Propertyname: {0}\r\n “, pi.Name);
 foreach (var a in pi.GetCustomAttributes(true))
{
  Console.WriteLine(” “ + a.GetType().ToString());
}
}

This code raised runtime exception “Unhandled Exception: System.Reflection.CustomAttributeFormatException: ‘ErrorMessageResourceName’ property specified was not found.” Whaaat!? I just checked that it is there. Reading the stacktrace more closely, I found ystem.InvalidOperationException: The resource type ‘MetadataTest.ModelValidationResource’ does not have a publicly visible static property named ‘XXX’.

Ok, so the resource should be public? Indeed, resources are generated as internal by default. Luckily the resource editor allows me to set the access modifier as public. Let’s retest. Now the new code goes through correctly. How about the code using TypeDescriptor? Now it works too! So, a few things to remember when using localized model validation

• Remember to set resources as public
• Do not trust TypeDescriptor as it silently sucks all exceptions and errors

I guess I need to ask Microsoft whether this is by design. Basically this kind of errors should never be ignored.

This post also got deleted in hacker attack. It was mainly about my talk in a Nice tuesday event.

Documentation is often considered a distinct phase of software development. Very few admits enjoying documentation. It’s become the dark side of development which is most often tried to be left undone. The excuses are many, misunderstood agile software development processes being one the most recent. “We use Extreme Programming – we don’t make any documents!”

If documentation is kept as a separate phase, performed after coding, we will face similar problems as we do if testing is postponed until coding is finished:

1. When we run out of time, the phase in question won’t get done
2. The phase will be an enormous effort and unpleasant as such, we are coders after all. Documents are easier to write in smaller parts. For example, writing down what you have accomplished this day isn’t such a big deal. It’s easier to write when you still remember what you were thinking.
3. The task is easily given to someone else. It’s most efficient when the same person wo wrote the code, also writes the documentation.
4. The outcome of the phase are of no use to the previous phase: if documents are written/tests done along with coding, it will be profitable immediately. You’ll think about your code from a different point of view and you may even find a major flaw in your design!

I hear often “I’ll document the code when it’s finished”. But as often the code will get taken to production before it’s ready. And at that point there’s no documentation.

So, always document your code as you make progress!

Christmas is wonderful time for reading. You don’t have anything more meaningful to do anyway

Mike Cohn‘s Agile Estimating and Planning happened to be on top of my reading stack. What a wonderful book it is! It stroke right into my thinking about conscious development. He provided excellent advice on estimating projects, prioritizing features, planning projects, planning iterations, calculating benefits, communicating progress, scheduling etc.

Most often these things are either done hastily or not at all. But you really have to do them, and do them consciously.

Most projects contain a tremendous amount of uncertainty. This uncertainty is often not fully reflected in the schedules and deadlines that project teams create. There are times when this uncertainty is so large or significant that extra steps should be taken when estimating the duration of a project.

The bottomline is this:

• You have to be able to justify any user story / project
• Do the planning, make the plans visible, and change them as needed
• Admit the uncertainty there is and plan for it
• Make wise estimates don’t just have a guess

Highly recommended to everyone! Really, I can’t say is this book for developers or managers. It gives excellent advice for project managers and project owners on prioritizing features, on the other hand, it says a lot about estimating the size of a user story – an activity best done by a developer.

It matches my thinking: there should be no project managers, developers and customer – there should be unified teams. And this book is excellent reading for a team!