It's about knowing where to hammer the nail - not hammering it

You could give me full access to a Bunnings Hardware store and all the time in the world and I could not build a better house, than a builder with a saw, a hammer and two pine trees!

Good tools are useful, once you know what you are doing. Microsoft Project, Niku, Source Control Software, Visual Studio, XML Spy, Issue tracking systems etc, are of no use to you, if you don't know what a good software system or well managed project looks like or how to make one. If you do, some good tools will help immensely.

No matter what Microsoft and other ISVs would have you believe, no software can do your job for you.

The Customers INTERESTS are always right

In software development, the customer is very rarely right! Usually, they come to you asking for some new feature like integrating everything they've ever done, with Excel, or demanding all their fetures now be exposed to all the other departments in the company via web services, or something along those lines.

Often, the demands are based on what they used to do with their last system, or what has just been discussed at a seminar they went to. Usually their "requirements" are based on what they've seen or heard someone or something else do.

Users can't be expected to think out of the box, with regards to I.T. solutions. It's not their job anyway - they have a business to run...what they are never wrong about though, it that they have needs that are to be fulfilled. They want a void filled, or they want something better... They won't always articulate these needs properly - often trying to do the job of your business analyst for you, but positive, respectful discussion, suggestions and proposals will always win the day. Occassionally, their solution may happen to be the right way forward as well - in this case, you need to give them their time in the sun. Othertimes, you may have much more cost effective solutions, that are a much better fit with your environment and meet their underlying needs better than what they asked for in the first place - when this happens, for the sake of you and your team, and future exchanges, you need to always bring the conversation/exchange back to the original request and make it clear that it was that initial request that sparked this idea, and that it is that user (group) that is responsible for this outcome - I.T. guys can have no ego!

MS Reporting Services and SQL Server 2005 and Visual Studio 2005

For the record, and in case anyone lands here in a frustrated search for info:
You can't write Microsoft Reporting Services reports for SQL Server 2000, using Visual Studio 2005.

It goes like this:
Visual Studio 2005 - SQL Server 2005 with Reporting Services
Visual Studion 2003 - SQL Server 2000 with Reporting Services.

So, if you're moving on to VS 2005, but have reporting services projects, that must run on SQL Server 2000, don't get rid of VS2003 just yet...

Here's a thread on Reporting Services newsgroups...

The accounting system

In the last month, I've dusted off the old accounting system code again and am chipping away at some GL functionality.

I've decided to blog the progress/ideas/lessons learned - here - for a record of some stuff I usually forget and also as motivation to keep it up this time.

Delegates

I'm always confusing this...

For future reference;

• Declare the delegate which defines the "class" for the event you're going to raise - with parameters etc
• Declare the event - of type "delegate" - with the parameters.
• Write a private function to handle calling the event - check for null event object first.
• Then just call the private function whenever you want to raise the event.

public delegate void EventNameHandler(type paramName);

then;

public event EventNameHandler EventName;

then;

private void OnEventName(type param)
{
if (EventName != null)
    {
        EventName(param);
    }
}

Then, in the consuming class;

classWithTheEvent.EventName += new EventNameHandler(localFunctionName);