Teknologika

I was looking for some reference information for recommending to a customer how to choose between Web Services or Remoting to connect to an external server or components on another physical server of a three tier architecture. If you are faced with such a decision I would recommend starting your research with these two MSDN articles:

ASP.NET Web Services or .NET Remoting: How to Choose
Performance Comparison: .NET Remoting vs. ASP.NET Web Services

In modern motor racing, such as formula one, each car is wired with a multitude of sensors that detect almost every possible influence or reaction on the racing car that it is possible to measure. Ride height, suspension travel, wheel spin, steering input and many other measurements all get recorded and analyzed in an effort to squeeze some more performance out of the race car. During a race engineers will monitor the engine performance and fuel consumption in real-time to help the tactical decisions that are made during a race, or slow the car down to avoid an impending engine failure. After the race is long over the data is analyzed to help tune the setup of future events and help evolve the car in an effort to win future races.

Software development can benefit in exactly the same way from this type of analysis and monitoring. Unlike a race car it isn’t necessary to purchase specialised measuring equipment to record data, as it is mostly already being recorded. However, like the racing counterpart it is necessary to spend some effort to yield some useable information and valuable results.

One of the most valuable tools that is available to a Software Development team are the statistics and metrics that can be recorded during a project, as it progresses, or in a post mortem at the end of a project. These different types of measures provide tactical and strategic benefits to an organization during a project. Tactical metrics are produced at a regular interval throughout the life of a project, (usually daily) and provide a close to real-time view into the health of a project.

Tactical metrics are typically produced by the test manager and include the defect trend graph, The defect trend is the single most valuable indicator that I use on my projects, it is the closest thing to an electrocardiogram (ECG) that I have seen for a software project. This graph plots active defects over the life of the project and provides one of the most valuable insights into the progress of both the testing system and the quality of the product itself.

So what exactly is an active defect? An Active defect is any defect that has not been closed, regardless of where it is in the defect cycle. For example, if a fix has been completed and is ready to be verified by a tester, is still counted as an active defect.

Other graphs that are quite valuable include reports that identify the most unstable components in the system, and test execution reports that indicate the amount of test coverage.

Another key graph is the “worm”, which shows daily how you are actually progressing compared to the original plan.

Walking away from the SDNUG meeting, and discussing life the universe and coding over a guiness with a co-worker, the conversation drifted to the standards of knowledge that developers aspire to in relation to their craft. What we really couldn’t wrap our heads around is how a lot of developers aren’t typically aware of where they are, (knowledge wise) relative to the top end of their industry and trying to continiously raise the bar for themselves.

Travelling home (a 40 minute train ride gives plenty of time to think!), I remembered that in a course somewhere that I attended a few years ago there was a slide that rated four different types of “competencies” that a person could have.

• Unconsciously Competent
• Consciously Competent
• Consciously Incompetent
• Unconsciously Incompetent

This led me to the conclusion that developers definatley fall into these four categories and the differences between an average developer and the good ones can be quite significant and very obvious once you have seen a great developer in action.

I am not just talking about ability to code here either, whilst knowledge of frameworks and programming concepts is important if not critical, knowing the role that you play as an individual developer on a project or team, and how you can affect the success or failure of the overall project or team is also a critical aspect of the developer who is “aware”. For example, the feature you are currently working on, are you developing on time, and on budget? Neither? Both? What is the impact to the overall project if you are late? Have you told the program manager that you will be late, the second that you know that you won’t hit the 5pm Friday deadline that everyone is expecting?

Some developers seem to be completely happy to Clock in at 9:05, surf the net for 1/2 the day, accept poor requirements, make inaccurate estimates, complain that there is not enough time, deliver code that is slow, buggy, unmaintainable and late. Whilst others are consciously on the road of self improvement.

So I pose the question, to ask yourself where do you sit on the scale, and are you investing enough in the corporation of one that is yourself?

Where can I start?

I think that everyone needs to ensure that they have a firm grasp of the basics. For the .net developer I would recommend the following as books that every developer should own, read and understand.

The Software Engineering Body of Knowledge provides a framework for software engineering knowledge, and may also be worth a look.

Learning is important, but the biggest single thing that will influence the way you develop is your attitude. Even though you may not be the best at what you do today, chances are if you define some goals and work towards them, chances are you will reach them someday, and that day may come sooner than you think.

According to a recent Microsoft webcast, VSS 2005 (I am yet to see and play with the product), VSS 2005 has several new key features:

• Http based remote access
  
• Performance improvements
  
• Support for a Copy-Modify-Merge development model in addition to the current lock-Modify-Unlock model of the current version.
  
• Prorogation of renames/deletes
  
• Support for 3rd party merge modules
  
• Support for unicode and multiple languages