Wednesday 28 April 2010

The things alcohol make you do

A consultant and a developer went to a bar.....

And after a few drinks they got into a stupid discussion on how bad programmers are.

One said that most programmer will look at a class and if they will think that they will only need a single instance of that class in their system they will instinctively make that class a Singleton.

The other would not accept the fact that this can be.

So who do you think is right and who is clearly mistaken?

and while you're at it, can you tell who said what?


Managing a one man project

Ken Egozi asked me to put an answer I gave on the Alt.Net mailing list so here goes.

the thread started by someone asking for an online Gantt service and later evolved on how to manage a project without the use of a Gantt. the specific project is quite small - about 2 months total and will be done by a single person. however the client is pressured and want to be sure that it can be done by the specified target date.

Here's what I wrote:

If I were you I would start by:

write down in a list all the things need to be done (from the point of view of the client). not the technical 'how', just a list of things that define "what' needs to be done.

after you have your list, sort it by priority and roughly estimate how long each item is going to take you.

when you finish, take a step back and look if everything make sense, i.e. you can complete it in the given time.

Next step is taking the first month or so, and dive into details. plan out your next 4 weeks in details trying to figure out exactly what are the technical steps needed in order to complete every item on your list. (in most cases this kind of details does not interest the client, it is used by you to track progress and verify that you are on the right track). When you finish define your first milestone to contain all the items from the initial list you know you'll be able to finish in the first 2 weeks. (make sure not to over commit).

at this point you should notice that everything adds up, i.e. if for some reason after going into details things looks they are going to take longer make sure to reflect that back on the content of your project.

Now you can go to your client and:

  1. agree with him on a delivery point/milestone every 2 weeks.
  2. show him your commitment for the first 2 weeks.
  3. show him a rough layout for the rest of the plan
  4. agree with him that after 2 weeks you will review progress and update the plan as needed.

if you want I can email you an excel backlog template I'm using to track and manage my pet projects. It's build for this kind of management and might help you to put things in context.

Lior

What I actually described here is a very simplified Scrum process. In my opinion it will work in this context as is mainly due to the fact that this is a one man project (and a relatively short one). This simple version will most likely not be great for a bigger team.

I was also asked to put somewhere excel template that I would use for such thing. So here's a link to a zipped file containing simple templates for both a product backlog and an iteration backlog (which either of them can be used for this specific context).

Monday 26 April 2010

What Have we Learnt Today?

As usual during the Practical Scrum Course I’m giving. At the end of the first day I gather some feedback in the form of two questions I ask:

  1. What was the most surprising thing you have heard today?
  2. What is the most controversial thing you have heard today?

here are the (unedited) answers I've got this time:

The Most Surprising

  1. How much client expectation can effect estimations
  2. That in some projects a client can get a new version every couple of weeks
  3. New approach to estimations.
  4. That in 4 weeks we should finish X features (development, testing and documentation) and make them ready to be shipped.
  5. Its important to leave room for “exciters” features.

The most controversial

  1. Less documentation if at all.
  2. Priority Poker technique
  3. Everyone using a waterfall approach is following a “flawed" model
  4. That “loaded” requirements document can cause estimation to increase
  5. There is not enough consideration for the unexpected.

JustMock – New Mocking Framework

The world of unit testing in .NET has recently become just a little more interesting. This month Telerik has announced the beta of their new JustMock mocking framework.

The interesting thing about this framework, is that for the first time a new tool is actually trying to compete with the power of TypeMock’s Isolator framework.

JustMock, like Isolator, is using the CLR profiler API in order to intercept method calls, allowing mocking of virtually any kind of class/method in your code. Including static methods, private methods, sealed classes and more.

At a first glance JustMock API looks very similar to the AAA syntax of the Isolator tool, what I did notice howeverare two main differances:

  1. It appears that JustMock has two modes of operation. The standard mode, in which the profiler is not enabled, allowing mocking only ‘overridable’ methods and an advance mode in which the profiler is used and every “feature’ of the tool is turned on. On the upside disabling the profiler should yield better performance, however once you decide to use any of the advance methods (even in a single test) the profiler is turned on for everything. I suspect that the actual reason for this lies in the old Design For Testability debate in which many states that using such a powerful tool might cause a degraded design. giving this two modes of operation allow everyone to choose whether he wants to allow advanced usage of the tool or to enforce a more rigid design strategy.
  2. A quick comparison of the beta version abilities to that of the Isolator framework. shows that at this point JustMock is in its initial stages and is lacking many of the Isolator capability. However, according to its documentation, the most desired ability to mock classes from mscrolib.dll is fully supported. This means that finally we can mock out things like the file system, the system clock all kinds of collections and more.

Whet is left to be seen, is how long will it take Telerik to close the gap between their beta version to a mature release which can actually compete with other mocking frameworks out there. And of course what will be the pricing of this framework (nope its not going to be open sourced or free).

On my side I’m very happy to see more tool options out there, believing that the resulting competition will benefit all of us. Also i plan on diving deeper into JustMock getting a better understanding on its actual usage and limitations.

Sunday 18 April 2010

Resetting Visual studio

Lately I've been working on some visual studio add-ins and plug-ins. I'm testing a few new ones and even playing around learning how to develop one of my own. Doing so did cause me to break the IDE leaving me in all sorts of weird situations. For example one time I messed it so bad I couldn't even create a new .NET project any more. For some reason the IDE insisted that I'll install some language tools (or something alike).

In the past this got me into a reinstall process which in most cases does solve the problem however does take about an hour or so.

Lately, I found that in most cases, issuing a reset command does in most cases solve the problem as well. So when having problems with VS-IDE before reinstalling try the following:

Reset the Visual Studio IDE

using the command: devenv / resetsettings.

note: it might be worth backing up the current setting to avoid the need to set everything again after a reset.

thank you Steve for this post

Reset a specific Add-in

using the command: devenv /resetAddin AddinName.Connect

note: this should reset the Add-In to its original state, which should make it work again.

than you Roy for this post.

More command line switches can be found here

Wednesday 14 April 2010

Don't be a Smart Ass Coder - Exercise in Rafctoring

Here's a piece of code I saw the other day.

the code is for real and given after massive renaming to protect the guilty

for ( int j = 0; j < 2; j ++ )
{
if ( j == 0 )
pObject = Repository::GetInstance()
->GetObjectByHandle(
pParent->GetPartAHandle());
else
pObject = Repository::GetInstance()
->GetObjectByHandle(
pParent->GetPartBAHandle());

if ( pObject )
{
ObjectGeometry objectGeometry =
pObject->GetGeometry();

for ( UINT i = 0;
i < objectGeometry.NumRectangles();
i ++)
{
Rectangle* pRect =
Repository::GetInstance()
->GetRectanglesByHandle(
pObject->GetRectnagleHandle(i, 0));
if ( pRect )
m_Repository.DiscardRect(
pRect->GetHandle()
);
}
m_Repository.DiscardSpread(
pObject->GetHandle());
}
}

First reaction was WTF !@$^@%@%^

Second reaction was common your not serious

after thing really sunk in, it was "Smart Ass"

Don't be a Smart Ass coder

Really don't! showing how smart you are through code serve no other purpose other then boosting your own ego. the immediate effect however is that it takes just a bit longer for other people to read your code. Yes you probably can deal with that, but show some respect to other people time. why do you make me read such a thing. cant this be made simpler?

of course it can, lets do that:

Step 1

the chunk of the method in fact clear some stuff in pObject, lets state that:

for ( int j = 0; j < 2; j ++ )
{
if ( j == 0 )
pObject = Repository::GetInstance()
->GetObjectByHandle(
pParent->GetPartAHandle());
else
pObject = Repository::GetInstance()
->GetObjectByHandle(
pParent->GetPartBAHandle());

CleanObject(pObject);
}
void CleanObject(Object pObject)
{
if ( pObject )
{
ObjectGeometry objectGeometry =
pObject->GetGeometry();

for ( UINT i = 0;
i < objectGeometry.NumRectangles();
i ++)
{
Rectangle* pRect =
Repository::GetInstance()
->GetRectanglesByHandle(
pObject->GetRectnagleHandle(i, 0));
if ( pRect )
m_Repository.DiscardRect(
pRect->GetHandle()
);
}
m_Repository.DiscardSpread(
pObject->GetHandle());
}
}

Step 2

do we really need a for loop with this weird if statement? Not really, in fact using the loop index for branching is probably a code smell.

Also who loop until 2?

use the oldest counting scheme (1, 2, many) and only when reaching many use a for.

so getting rid of that we get to:

pObject = Repository::GetInstance()
->GetObjectByHandle(
pParent->GetPartAHandle());
CleanObject(pObject);

pObject = Repository::GetInstance()
->GetObjectByHandle(
pParent->GetPartBAHandle());
CleanObject(pObject);

Step 3

The resulting CleanObject is doing two things:

  1. Clean all the rectangles inside object.
  2. Clean up the object itself.

Let separate those:

void CleanObject(Object pObject)
{
if ( pObject )
{
CleanRectnagles(pObject);

m_Repository.DiscardObject(
pObject->GetHandle());
}
}

void CleanRectnagles(Object &pObject)
{
ObjectGeometry objectGeometry =
pObject->GetGeometry();

for ( UINT i = 0;
i < objectGeometry.NumRectangles();
i ++)
{
Rectangle* pRect =
Repository::GetInstance()
->GetRectanglesByHandle(
pObject->GetRectnagleHandle(i, 0));
if ( pRect )
m_Repository.DiscardRect(
pRect->GetHandle()
);
}
}

Step 4

For good measure lets simplify CleanRectnagles even further:

void CleanRectnagles(Object &pObject)
{
ObjectGeometry objectGeometry =
pObject->GetGeometry();

for ( UINT i = 0;
i < objectGeometry.NumRectangles();
i ++)
{
CleanRectnaglesExtracted(pObject, i);
}
}

void CleanRectnagle(Object &pObject, UINT &rectIndex)
{
Rectangle* pRect =
Repository::GetInstance()
->GetRectanglesByHandle(
pObject->GetRectnagleHandle(rectIndex, 0));
if ( pRect )
m_Repository.DiscardRect(
pRect->GetHandle()
);
}

Final Result

and we end up at:

pObject = Repository::GetInstance()
->GetObjectByHandle(pParent->GetPartAHandle());
CleanObject(pObject);

pObject = Repository::GetInstance()->
GetObjectByHandle(pParent->GetPartBAHandle());
CleanObject(pObject);

void CleanObject(Object pObject)
{
if ( pObject )
{
CleanRectnagles(pObject);
m_Repository.DiscardObject(
pObject->GetHandle() );
}
}

void CleanRectnagles(Object &pObject)
{
ObjectGeometry objectGeometry =
pObject->GetGeometry();
for ( UINT i = 0;
i < objectGeometry.NumRectangles();
i ++)
{
CleanRectnaglesExtracted(pObject, i);
}
}

void CleanRectnagle(Object &pObject,
UINT &rectIndex)
{
Rectangle* pRect =
Repository::GetInstance()->
GetRectanglesByHandle(
pObject->GetRectnagleHandle(
rectIndex, 0));
if ( pRect )
m_Repository.DiscardRect(
pRect->GetHandle() );
}

Food For Thought

It still doesn't look clean enough. Looking closely one can easily spot misplaced operations. CleanRectnagles really looks like it belongs to Object class. The same holds true for CleanObject and CleanRectnagle. Was that so obvious in the original code?

CleanRectnagle can use an additional simplification, resulting in a clean method which belongs to the rectangle class.

etc, etc...

Summary

Take a look back at the initial piece of code, yes its a little shorter then the resulting code. However how long would it take you to understand it?

Remember when writing code the goal is not to show how smart you are the goal is to write simple straight forward code which is easily understandable all programmers reading it later.

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Walgreens Printable Coupons