John Howell

In training a developer new to object orientation, the discussion of encapsulation took a turn into composition. It all started with the developer attempting to make an object completely stand alone. When he was done, the object was so bloated with code that you practically had to use a wheelbarrow to move it around. Rather than drowning the boy in design patterns I tried a different approach. I tried to explain that although his intentions were good, how he went about it was not. In his efforts to encapsulate everything relevent to the object, he had also begun to encapsulate functionality in such a way as to make the object a composition of functionality. When we first learn to develop, our throughts tend to be sequential and subsequently, we lay our code down the same way. What that does is to combine the code into streams of functional activity. The coder sees what they want to put in and what they want to get out and think that the gigantic mound of code in the middle ‘encapsulates’. It does not. Say it with me: segregate, segregate, segregate. To keep our code agile we must break out functionality in the same way that we break out the changable v/s non-changable portions of our code. What I did to help the developer was to help him see the individual pieces of functionality and help him begin to move those out into separate classes that will manage that functionality for him (I didn’t break it to him that he had just started his journey down ‘behaviorial programming’! 🙂

When you’re teaching or training or simply helping another developer, don’t show off how many technical or OO or DP terms you know. Rather help them by guiding them to the point where they can discover how best to architect their code. They’ll learn more, appreciate and respect you more and you’ll have a much better developer.

There is an excellent article on MSDN on scaling SQL 2005. It’s well worth reading and reading again!

Just in case you didn’t get the hidden enthusiasm,
SQL SERVER 2005 ROCKS!

I know everyone already knows about this. (It’s two days old already 🙂
The Express Suite of products will be FREE FOREVER!!! That’s right C#, VB.Net and the Web Express kits!!! All of them!

But to make it completely clear, here is Dan Fernandez’ blog entry. Believe it! You have got to take a look at the new samples and starter kits, they are really exciting!

Another OO lesson:

When working with complex objects, try to view them in groups of behavior. Don’t view it as one gigantic object, split it into behaviorial groups. You can then take advantage of so called ‘lazy’ or ‘late’ instantiation. For example, you might have an “Insurance Policy” object. You don’t want to retrieve and build the entire object every time. That would cause poor performance and memory overhead.
Instead have a minimum set of properties that are always retrieved and then group the remaining into separate objects. For example, coverages, underwriters, auditors, etc. You can then break those subgroups into smaller late instantiated objects as well.

A little extra though now will save you a great deal of performance pain later!

We have some great tools at our fingertips but not all customers can migrate to 2005 right now so we need to not only be able to develop in 2005 but support our existing customers in VS2003/SQL2000.

One solution is to use Virtual PC. I’ve used it since 2004 and it does work well enough. The quirks are managable but performance can be problematic. And unless you’re running a Quad, you really should only run one VPC session at a time. Virtual PC Server is better, but still the same concept.
Microsoft already had this in mind when they began to prepare the 05 release. You CAN run both sets side by side. There are only a couple of minor things to do to make this a much better development environment.

To make this happen, you should install the software in this sequence:
Prerequisite: a. Make sure IIS is already installed and running.

1) Install SQL 2000 and then install the latest service pack
2) If you need Reporting Services, then install it now (along with any service packs)
3) Install VS2003 full install
4) On the installed SQL2000 go to Server Network Utility and enable just the TCP/IP protocol. If Named Pipes is also enabled, disable it.
5) Now run the installer for SQL2005 and install just the Client Tools (Workstation Tools and Documentation Option in the installer).
6) Once the client tools are installed, go to Start->Run->SQLServerManager.msc and enable the Shared Memory in the Client Protocols section under SQL Native Configuration
7) Now run the SQL2005 installer. Please ensure that the account under which the services are run is an administrator of the machine and has all rights.
8) Reboot
9) Install VS2005 full install
10) Reboot

You know have a machine that you can develop in both VS2003/SQL2000 and VS2005/SQL2005.
Note that you can swap between ASP 1.1 and ASP 2.0 using the ASPNET_REGIIS utility or even better use Denis Bauer’s ASP.NET Version Switcher. It’s a breeze!

A few weeks ago, I had raised the question of the validity of OO development in the current technoligical environment. It was intended to make people think and remember why we architect apps the way we do (OOA, OOD, OOP).

However, there are still quite a few people mired in the ‘disposable code’ mindset and as a result, I have deleted a couple of posts just to clear the air.

I still intend to make people think before they code but I won’t do it so confrontationally.
For now, we’re going to get back to architecture, OOD and OOP. Sorry for the interruption.

Some time back I really stirred the pot by telling a tale about two programmers: one used datasets and flat architecture and one used full architecture and domain models. In that tale, I made it seem like it was easier for the first developer to get something out the door. In this tale, we come back to the developers a year later. Mounds of functionality has been added and many changes have been made. One day the manager comes in and says “We’re converting our app from a desktop app to a web app. And the data will all come from Web Services.“. The two developers are stunned. But the second developer has a good object architecture and good layer segmentation. The task is a big one but in his/her case, only the UI and the direct db access portion of the DAL are changing. In the case of the first programmer, the task is so big that the current code is almost a complete loss.

There are pros and cons to every development method. But today’s developers must be of a different mindset. We must develop with the intent of creating ‘living code’. Code that can adapt to today’s rapidly changing environments. The only way we can do that is to develop good architectures, good OO skills and patterns and good segmentation. Refactoring is the only way to keep the code alive and growing. ‘Write once and live with it’ type code is no longer an option. We have to ‘write, reuse, refactor, extend’. If we don’t write it in such a way that we can reuse, refactor and extend, then we’re just wasting time.

OK, after my last post, I had to just sit down and try a few things. One of the things I had to try was to write an app the old fashioned way (code heavy form, no DOM {Domain Object Model}, no framework). Pretty much a horizontal application.

It was even more frustrating than the mountains of code I have been writing in building DOMs. I don’t know if I’ve become completely dependent on having a good architecture to code against or if I’ve simply lost the patience to write such disposable code.

I know Mark Miller hates intellisense, but I live by it. I can write much more code with many less keystrokes with it. And many of my mistakes are caught by the compiler instead of in testing. And I think that’s the item I’m not going to be able to do without by not building a DOM for all of my apps. If I do build a DOM, most of the problems are caught before testing. And the errors that are caught in testing are problems that are common among the objects in the DOM and can be resolved across the board.

With that said, I think that the problem is not in the architecture, but in the tools. If I had a tool to deal with the mundain DAL and the generic data portion of the BOL then most of my frustrations would be eliminated.

Someone once said, when all you have is a hammer, then all you see are nails. We need more tools to help build better apps.

In the beginning was the data and the data was good. All we cared about was getting the database populated and getting our queries to run fast.

Then came Objects. And they too seemed good, but they really just wrapped our data and presented in an easy to use fashion. The data was still there.

Then came Components. They wrapped up our objects and were even easier to use. But, still at the bottom was the data.

Then came Services. They abstracted away the Components. But the data remained.

So developers are pushed to build Domain Object Models and Components and Services all to do what? Make it easier to develop against? Use some cool new toys?

Back in the VB6 days, we grabbed a connection, pulled a RecordSet, pushed on a form then updated as needed.
These days were supposed to do what? Oh, the same thing you say, just after we develop the DOM, the components and the services?

We’re so old now that we’ve come full circle. Users don’t really care about DOMs and Components and Services. They care about:
1) How the app looks
2) How fast you can deliver
3) How fast the app runs
4) It’s right

And in that order! We’ve gotten lost in the hype. As developers, we’ve lost our way. The real truth is in this list. And that should translate to how we develop software. Technology will change, UI’s will change, OS’s will change, but the data will always be there. That’s were the real value is.
Somehow we must get back to the basics of building applications, not software development.

We have to get back to delivering something that meets our client’s needs.

My blood is as blue as the next programmer’s, but this time I’m left wondering.

I am a firm believer that Microsoft’s development tools are the best as far as making a developer productive. I also believe that the Office suite is very good (notice I did not say great or the best). However, Office is ‘good enough’ and is one of those tools that has gone far too long without major updating (like IE). It is really a diamond in the rough. A perfectly ripe fruit that needs the hard labor that all farming does to bring it to harvest.

Enter stage left, Sinofsky. He’s the one that has been handling the Office suite. His firm regimented management style has kept Office releases on schedule. However, that same management style has not allowed any major innovation or interoperability in years. So now, Allchin steps down and hands the reigns to Sinofsky. Was this meant to be a slap to the COSD team for missing release date after release date? Sinofsky, the same man who, when another team might delay his Office release, side stepped the team and ‘did it theirselves’ and sacrificed interoperability.

Enter stage right, Nash. What could we not say about this guy. He pretty much single handedly turned Windows from a security laughingstock to a serious contender. The same man who spent most of ’03 sleeping in the MSRC handling the attacks as they came in and personally handing the STUs to get them out the door. The same man that said that Microsoft could and should respond faster. The same man who turned in his ‘security keys’ to the kingdom today. Today, the same day that Microsoft announced that Sinofsky was now the ‘man in charge’.

As I said, I’m a Microsoft believer, but I’m worried that this is yet another misstep by the company. When they wasted a not-so-small fortune to bring in Ozzie with his half-baked and blue-sky ideas, I stayed awake many nights worried that he would lead them astray. With Microsoft “Live” coming to life like Ozzie’s Frankenstein, is Sinofsky the stake in the heart?