Food for thought...

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?

To clarify the last post...

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.

URGENT ASP.NET 2.0 WARNING

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.

Great demo of LINQ

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.

WinFX is now GO-LIVE!!!!!

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.

Architecture and Objects are worth the extra work!

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.