John Howell

Sorry to be silent for so long, I’ve been working on a project. (Gotta pay the bills you know).
I’m one of those programmers who try to get the code right the first time. I will spend extra time up front on architecture and refactoring so that I’ll find less bugs in testing.
In working on this project, I’d written about 50,000 lines of code and was testing when I had a strange error. It only took me a few minutes to track down, but it was a missing “@” sign from one of my procedure parameters. I noticed that if I had lined up my procedure names as I usually did, I would have spotted it in coding, but I had been in a hurry and did not take the time to make it neat. I think that if at all possible you should make your code as neat and lined up as possble to make it easier for you to spot these types of problems. Life doesn’t usually give you the time to do it, so you sometimes just have to suffer.

Just so you know, I did write a decent sized program that worked perfectly the first time. That was the only time and I’ve been striving for it again ever since.

In case you haven’t heard, there are some great code snippets available for VS05 from MS at
http://msdn.microsoft.com/vstudio/downloads/codesnippets/default.aspx

A good saying to keep in mind when looking at someone else’s code is:

Never attribute to malice that which can be explained by incompetence
Richard Campbell

OK, I know that my previous posting intended to provoke discussion could have actually been framed better. (The flames are still flickering!) So to make up for it, I’m going to post some emails regarding the issues I was hoping people would bring up and discuss. So in the near future I’m going to send out some emails regarding Object Framework Performance to discuss:

Proxy driven properties
Late bound / creation of objects
Object destructuring for the purpose of composite object building using interfaces
Performance loading object collections

The code for the examples will take a little time to put together so be patient.

A Tale of Two Programmers

In a software development shop far, far away, there were two programmers. There each had years of experience and each had been successful. Yet each viewed systems in different ways. The first programmer viewed systems as objects interacting with each other. As a result, he developed object frameworks for each system he developed. The frameworks were clear and well thought out and were easy to work with. The second programmer viewed systems as tools to work with data. He felt that the data and its interactions were more important and as a result developed his systems with far fewer objects whose main purpose was to work with data. His systems worked well and kept to the KISS principle.
One day, a manager came into each programmers cube and said “Your system is suffering from performance problems; you must tune it to perform better”.
Each developer began to scramble to find the performance problems.
The first programmer began testing each manager, factory, and collection manipulator objects to look for the performance issue. It was intensive and required the developer’s intimate knowledge of how the objects interacted.
The second developer began looking at his data and queries. He quickly found the few queries causing the performance problems. In a short time he had added a couple of indexes and changed the queries and the performance problem was no more. He was done and left for the day; a little late for dinner but not too bad.
The first programmer finally found the few spots in his framework causing the problems and began to refactor to alleviate them. After working through the night, he had the framework changed and the performance was now acceptable. He left to grab a couple of hours of sleep and then come back in to see how the system behaved (and to finish regression testing his refactoring changes!).

Although both programmers met the goal of adjusting their systems to meet the performance requirement, the second was able to more readily locate and more easily address the performance issue. Neither programmer was doing anything “wrong”. Both systems worked and now both systems met the performance requirement.

But the real question is, which developer would you rather be? The one leaving at a decent hour with the changes made or the one that worked through the night and ultimately got the same result?

OK, ok, settle down everybody, I didn’t mean for people to think that I was advocating putting your web DLLs into the GAC. I was simply stating the “official” workaround. I still feel that the GAC should only be used for system wide, commonly shared assemblies.
If you’re not dealing with aysync pages or tls (thread local storage), then this issue does not affect you.

This is just for those developing ASP.NET 2.0 web apps.

There are instances where IIS (and even more so Cassini) will swap your Thread from one AppDomain to another. What this means is:
1. Thread local storage content MUST be serializable
2. Any AppDomain that the thread is swapped to MUST have access to the assembly

The only current workaround offered is to simply store the assembly in the GAC. This is fine for releases but is a pain during development. On the up side, if your IIS is local, then I’m guessing that #2 would not be an issue.

OK, I know I get excited about some of this stuff even when it seems a bit esoteric, but LINQ will be something that will be of incredible benefit to us developers. Here is a link from MSDN TV that shows Paul Vick and Amanda Silvers demonstrating the power and simplicity of LINQ. This demo is in VB.Net and before Qasim sends me a jab about it, just take a look at how well LINQ and the new XML capabilities integrate with VB.Net.
The demo runs less than 30 minutes and is more than worth the look. This is great stuff and will really make our lives easier.

Go Live licenses for WCF and WF
Microsoft announced Go Live licenses this morning for WCF (Windows Communication Foundation / “Indigo”) and WF (Windows Workflow Foundation), which allow customers to use the January Go Live releases of WCF and WF in their deployment environments. (Note that these are unsupported Go Lives.)
More information about the Go Live program is at http://msdn.microsoft.com/winfx/getthebeta/golive/default.aspx.

OK, I just could not hold this in any longer. Most of the time, when I create a piece of software, I work on the design first, architecture second, code third. However, occasionally, I sucumb to the pressures of deadlines and “code from the hip”. You know the style, opening and connection and building dynamic SQL anywhere it’s needed, blending functionality (to speed development); just simply not architecting, but coding. The apps work and perform well, but it always comes back to bite me.

Take a recent app: It was critical that this app perform well and get out the door quickly. Rather than stand my ground and insist on an OF (Object Framework), OOA (Object Oriented Architecture) and OOD (Object Oriented Design), I threw the app together and got it out the door. Now, for the fifth time in a short period (since delivery), we’ve needed changes and each one has been a royal pain. I have another similar app that has a great OOA and OOD. The code base for the second app is larger by a factor of 10 and the performance is lower by about 30%. But, I can apply fairly significant overall code changes to the second app relatively easily. The first app met the customer’s immediate requirements but is now giving long term heartburn because of the time to make mods. The second app is causing a tolerable bit of heartburn with performance but they can get their business critical updates more quickly.

I think that OOA/OOD do cause significant performance hits, but with some focused code tuning, I think that you can at least make it tolerable. And by code tuning, I’m not talking about using StringBuilder rather than String, I’m talking about instead of doing 100 querys, maybe find a way to do one query and build everything from one dataset.

Anyway, the bottom line is that I think that every app needs to be well architected because you will ALWAYS have to return to it to make changes. So, make your live easier now and do it right.