Friday, November 5

Characteristics of an effective programmer.

A lot has been written on what makes a great programmer.
I'd like to write about what makes an effective programmer. The two can be different.


I would say the characteristics of an effective programmer are as follows:
  • 1) Do you know and care about how the application you are writing will be used, and do you have opinions about how to make it better?
  • 2) Do you know about new technologies, can you recognise those that should be adopted in your current projects and can you explain them convincingly enough to get them adopted?
  • 3) Can you maximise tha amout of code not written, through efficient design, reusing things that have been written before and eliminating unnecessary requirements?
  • 4) Can you recognise your limitations and mitigate these, e.g. by understanding where you need to learn something new or code defensively, and where to get help from others?
  • 5) Can you design and write code that can be maintained in 10 years time by someone of average ability, when tools and programming languages have moved on?
  • 6) Do you understand more than just code, e.g. databases, infrastructure and can you use this understanding to make it more likely a project will be stable and reliable when it is live?
Do you agree?

Monday, November 1

Planning poker with Return on Investment

A lot has been written on Planning Poker as part of an agile approach to developing web sites.

I have a new take on this - Planning poker with return on investment. I'm sure we all agree that things that give a lot of value with a small amount of work should take prioriry.

This would work as follows:

The stakeholders would divide into two groups, business people and developers. Business people would use planning poker to estimate the likely return of a proposed development in "return points". Developers would at the same time estimate the likely investment in "story points". "Return points" would likely be related to the amount of money the proposal would make. "Story points" would be related to the number of days development.

You can then divide return by investment to get a priority.

  • If return is small, investment big, it's probably best to forget the proposal.
  • If return is big, investment is small, it's a no brainer and should be done.
  • If return is small, investment is small, it's a medium priority.
  • A problem occurs if return is big and investment is big. This suggests there is a risk involved. To reduce the risk, the proposed development should be divided into smaller chunks.

Sunday, October 24

Feedback loops

Mark Needham describes overcompensating in feedback loops.

This reminded me of something from my control theory course at university many years ago. If you are not in a desired state, you should make changes that are a percentage of the difference between your current state and the desired state. You will gradually converge towards it, and not overcompensate for any sudden changes.

Wednesday, October 17

Visual Studio 2005 ASP.NET F5 Debugging performance

I was experiencing a delay of about a minute between pressing F5 to start debugging my ASP.NET application (VS2005 SP1, Vista) and anything appearing in the browser.

After researching this and installing various hotfixes, nothing improved. Removing the google toolbar however seemed to make debugging return to its normal speed.

Wednesday, September 5

ASP/ASPX pages giving 404 errors

In case I need to do this in future... I have been trying to copy a web site to a new web server (Windows Server 2003) and getting very confused about why .ASP and .ASPX pages were giving 404 errors, but HTML pages were displaying correctly. The reason was "ASP.NET" and "Active Server Pages" in the Web Service Extensions directory were both set to "Prohibited".

Wednesday, August 29

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

I was getting an error message "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel." when trying to connect to an HTTPS site using an HttpWebRequest.

As the site I was connecting to was a test site from a 3rd party known to me, but not set up correctly at their end, to bypass this check I added the following line before calling GetRequestStream on my HttpWebRequest.


ServicePointManager.ServerCertificateValidationCallback
+= new
System.Net.Security.RemoteCertificateValidationCallback
(CustomValidation);


and added the CustomValidation function as follows:


private static bool CustomValidation(object sender,
X509Certificate cert, X509Chain chain,
System.Net.Security.SslPolicyErrors error)
{
return true;
}