Tuesday, May 30, 2006
C# 3.0 got open classes
Still, C# is in constant flux :-) and in the 3.0 specification we have a concept of "extension methods", which is just another way to say "open classes". Finally, I do have a nice solution to many problems. Indeed, for a long while I entertained the idea of adding this feature to C++ (hacking on GCC) as a proof of concept. Well, someone else did it for me (though for a different language).
I should spare a little time to write something more comprehensive on the subject. Meanwhile, if you need a little inspiration on why this stuff can be useful, see my Clone Vs. Assign post: now I can add a ShallowAssign method to System.Object. This is just a small part of the picture: Meyers' insight on encapsulation provides another interesting perspective on how to use open classes (or, as I'll call them from now on, "extension methods" :-).
Monday, May 29, 2006
Unraveling complexity
During a break, the lead developer said that talking with me turned a complex problem into something simple. This is, indeed, one of the main contributions of experience: you learn to ask the right questions, see (and seize :-) any opportunity for simplification, add some perspective and bring some order into the chaos. Oddly enough, simplicity is not valued highly enough in many companies; for a nice anecdote, see the essay "Brilliance" in Tom De Marco, "Why Does Software Cost so Much" (a nice book to have, by the way).
I would have more to say on complexity, including Fred Brooks concept of essential and accidental complexity, and why I think we can change the complexity equation in many projects, but that will be for another day...
Tuesday, May 23, 2006
Requirements and Viewpoints
I've recently met a newly appointed product manager: young, energetic, truly customer-driven. Which is good, of course: focusing on customers is obviously a sensible marketing strategy. There is, however, a subtle difference between customers and users, which is often forgotten inside the money loop :-).
For sake of simplicity, I'll define "customer" as someone buying a product (that company sells products, not services) and "user" as someone who will actually use the product. Marketing is usually very concerned with customers (they will shell out the money), but in many cases, success or failure depends on satisfied users. Well, reality is more complex than that: success or failure depends on meeting the most important expectations of customers, and the most important needs of users. Which won't be easy in many real-world scenarios.
The customer might be the boss, the users the employees. They have conflicting needs. The customer might be the owner of a facility, the users his own customers. Again, they have conflicting needs. And so on. Focusing too much on a single side won't cut it: you need to keep both in your mind, all the time.
Again, the real world is more complex than that: we may have several different viewpoints influencing requirements all the time, including technological constraints, regulations, and so on. Unfortunately, all too often those viewpoints are kept hidden, which is a recipe for inefficiency. Making viewpoints explicit allows for better reasoning, better choices, better focus. I usually don't play too hard on the formal side of viewpoints: a clear statement of the main viewpoints influencing the project is often good enough (as usual, it's a dynamic document!). Those interested in a more comprehensive approach may want to read Requirements Engineering With Viewpoints by Gerald Kotonya and Ian Sommerville (Lancaster University).
Sunday, May 21, 2006
BetterEstimate™ 1.0a freely available
As promised, my BetterEstimate™ tool for probabilistic estimation of effort is now freely available on my website.
I'm also working on a comprehensive paper describing the rationale and concepts behind the tool. It's gonna take a while, so stay tuned :-).
I'm also working on a comprehensive paper describing the rationale and concepts behind the tool. It's gonna take a while, so stay tuned :-).
Monday, May 15, 2006
A little more value from semantic tags
The blog is quickly becoming the most visited part of my website, with all the rest slowly moving (or just standing still :-). A few weeks ago I used the semantic tags to make the "links" section alive, pointing to posts with interesting links inside. Today I've spent about 3 minutes adding a little more value for readers in the mood for more information :-). From the "links" section in my home page, you can now see a list of posts pointing to articles and books.
Sunday, May 14, 2006
Reach for the top, and the sun is gonna shine...
Today was somewhat cloudy here in Savona, but I took it for a ride anyway. The nice part of the toy is that besides looking at real time data, you can download all the raw data to your PC. The bundled software is not that great, but you can export everything to better tools. I haven't tried it with google earth yet, but I will sooner or later. Meanwhile, here is a chart of altitude Vs distance for today.
Overall I ran for 25 km, up to a 760m altitude. Well, "running" is a bit of an overstatement :-), especially on the way back :-).
As I worked my way to the top, the sun came out bright and shiny, and ran with me back home :-).
Tuesday, May 09, 2006
Evolution of C#
var obj = new SomeClass( p1, ..., pn) ;
instead of the redundant
SomeClass obj = new SomeClass( p1, ..., pn ) ;
Of course, we would always need the latter syntax to use polymorphism, but that's not the point. I don't like the idea because it's not removing the useless "new" part. It would be much better to borrow from C++ and use the declaration style for automatic objects:
SomeClass obj( p1, ..., pn ) ;
No redundancy, a clean syntax for anonymous objects:
SomeClass( p1, ..., pn )
and if you need polymorphism, just combine the two ideas:
SomeInterface obj = SomeClass( p1, ..., pn ) ;
Indeed, as I said in another post, "new" is totally useless in C#, as type declaration, not variable declaration, determines if the object goes on the stack or on the heap. It's actually worse than useless: it's making code unnecessarily verbose and more complex to read.
The syntax above would allow a clean language upon which we can build our own language by defining new classes; "var" is a kludge and does not significantly improve the language. (there is a role for something like "var" when using C++ templates, but that's an entirely different story, given the limited expressive power of .NET generics).
Tuesday, May 02, 2006
Knowing your real capacity
There is a magic step in most companies, when estimated effort is transformed into a schedule, and so in a delivery date.
In some companies the step is trivial - management is mandating the delivery date without even looking at the estimate. That's obviously a recipe for failure.
In most cases, however, the effort is somewhat allocated to multiple resources, a few external factors like holidays :-) are accounted for, and you get a schedule. I mean, an unrealistic schedule.
Indeed, most schedules are unrealistic even when the estimate is realistic. The reason is that most schedules assume that resources will be allocated 100% on the project, although it's pretty obvious to every reasonable soul that they won't be.
Resources are routinely distracted for several reasons. In many cases, those factors are collectively called "emergencies" or "crisis", but they are just the natural consequence of bad planning. Here is a (highly simplified) effect diagram (a la Weinberg) that I've drawn so many times for so many companies :-).
It all starts with some problem on the field: for instance, a customer experiencing some troubles. Since the schedule for the current project assumes 100% availability, resources are distracted. Note that having someone investigate the issue is a (sensible) management choice; it's the fact that no one is available (because the schedule assumes 100% availability) that causes resource distraction. Distraction leads to delay, and therefore to pressure to complete on-time; this is a natural consequence. In many cases, when the deadline approaches quality is compromised; this is a management choice (although in more than a few cases, the decision is taken at the development level). Here is the catch: if you compromise quality, you'll have problems on the field, creating a self-sustaining loop.
Now, we can try to break the loop with different techniques. We may artificially pad estimates; we may try to convey the message that "quality shouldn't be compromised", and so on. We can also face reality and understand that people won't be available 100% of their time. Ideally, we should measure their average availability: it's easier than it seems, if you don't get yourself carried out too far. We should also create a plan that it's both realistic (will deliver with good quality even if resources are distracted as usual) and aggressive (will make good use of resources if they are not distracted). The A/B/C metric from Todd Little would help here.
This will gradually reduce the amount of resource distraction (as you'll get less and less problems from the field once you don't compromise on quality), and therefore you'll be able to assume an higher availability of resources. Again, don't overshoot, as working on the edge is always dangerous.
In some companies the step is trivial - management is mandating the delivery date without even looking at the estimate. That's obviously a recipe for failure.
In most cases, however, the effort is somewhat allocated to multiple resources, a few external factors like holidays :-) are accounted for, and you get a schedule. I mean, an unrealistic schedule.
Indeed, most schedules are unrealistic even when the estimate is realistic. The reason is that most schedules assume that resources will be allocated 100% on the project, although it's pretty obvious to every reasonable soul that they won't be.
Resources are routinely distracted for several reasons. In many cases, those factors are collectively called "emergencies" or "crisis", but they are just the natural consequence of bad planning. Here is a (highly simplified) effect diagram (a la Weinberg) that I've drawn so many times for so many companies :-).
It all starts with some problem on the field: for instance, a customer experiencing some troubles. Since the schedule for the current project assumes 100% availability, resources are distracted. Note that having someone investigate the issue is a (sensible) management choice; it's the fact that no one is available (because the schedule assumes 100% availability) that causes resource distraction. Distraction leads to delay, and therefore to pressure to complete on-time; this is a natural consequence. In many cases, when the deadline approaches quality is compromised; this is a management choice (although in more than a few cases, the decision is taken at the development level). Here is the catch: if you compromise quality, you'll have problems on the field, creating a self-sustaining loop.
Now, we can try to break the loop with different techniques. We may artificially pad estimates; we may try to convey the message that "quality shouldn't be compromised", and so on. We can also face reality and understand that people won't be available 100% of their time. Ideally, we should measure their average availability: it's easier than it seems, if you don't get yourself carried out too far. We should also create a plan that it's both realistic (will deliver with good quality even if resources are distracted as usual) and aggressive (will make good use of resources if they are not distracted). The A/B/C metric from Todd Little would help here.
This will gradually reduce the amount of resource distraction (as you'll get less and less problems from the field once you don't compromise on quality), and therefore you'll be able to assume an higher availability of resources. Again, don't overshoot, as working on the edge is always dangerous.
Labels: project management
