As I’ve mentioned before, my mother is battling cancer. Due to this, I’ve spent more time in hospitals over the past few months than I have in my life before now. And in so doing, I’ve drawn some scary conclusions about where our industry may be headed.

When I got into the industry 20 years ago (yes, it’s true…), it was quite realistic to think that a hot-shot programmer could be an expert in everything they touched.

In my case, I got hired to write software on a DEC VAX using VAX Basic. Now, I was a dyed in the wool Pascal fanatic, and the idea of using “Basic” was abhorrent to me. But not as abhorrent as not having a job (this was during the Reagan-era recession after all), and besides, I loved the VAX and this was a VAX job.

What I learned, was that VAX Basic wasn’t “Basic” at all. It was a hybrid between FORTRAN (the native VAX language) and Pascal. A couple months later, I was an expert at, not only the VMS operating system, but at this new language as well. It was my sixth programming language, and after a while learning a new language just isn’t that hard.

My point is this: as a junior (though dedicated) programmer, I knew pretty much everything about my operating system and programming language. For that matter, I was versed in the assembly language for the platform too, though I didn’t need to use it.

Fast-forward 8 years to 1995: the beginning of the end. In 1995 it was still possible for a dedicated programmer to know virtually everything about their platform and language. I’d fortunately anticipated the fall of OpenVMS some years earlier, and had hitched my wagon to Windows NT and Visual Basic. Windows NT was, and is, at its core, the same as OpenVMS (same threading, same virtual memory, etc.) and so it wasn’t as big a shift as it could have been. The bigger shift was from linear/procedural programming to event-driven/procedural programming…

But, in 1995 it was quite realistic to know the ins and outs of VB 3.0, and to fully understand the workings of Windows NT (especially if you read Helen Custer’s excellent book). The world hadn’t changed in any substantive way, at least on the surface, from 1987.

Beneath the surface the changes were happening however. Remote OLE Automation arrived with VB 4.0, rapidly followed by real DCOM. SQL Server appeared on the scene, offering an affordable RDBMS and rapidly spreading the use of that technology.

(Note that I’d already worked with Oracle at this point, but its adoption was restrained by its cost. Regardless of the relative technical merits of SQL Server, its price point was an agent for change.)

And, of course, the HTTP/WAIS/Gopher battle was resolved, with HTTP the only protocol left standing. Not that anyone really cared a lot in 1995, but the seeds were there.

Now step forward just 3 years, to 1998. Already, in 1998 it was becoming difficult for even a dedicated developer to be an expert in everything they used. Relational databases, distributed programming technologies, multiple programming languages per application, the rapidly changing and unreliable HTML and related technologies. And at the same time, it isn’t like Windows GUI development went away or even stood still either.

Also at this time we started to see the rise of frameworks. COM was the primary instigator – at least in the Microsoft space. The face that there was a common convention for interaction meant that it was possible for people to create frameworks – for development, or to provide pre-built application functionality at a higher level. And those frameworks could be used by many languages and in many settings.

I smile at this point, because OpenVMS had a standardized integration scheme in 1987 – a concept that was lost for a few years until it was reborn in another form through COM. What comes around, goes around.

The thing is, these frameworks were beneficial. At the same time, they were yet another thing to learn. The surface area of technology a developer was expected to know now included everything about their platform and programming tools, and one or more frameworks that they might be using.

Still, if you were willing to forego having friends, family or a real life, it was technically possible to be an expert in all these things. Most of us started selecting subsets though, focusing our expertise on certain platforms, tools and technologies and struggling to balance even that against something resembling a “normal life”.

Now come forward to today. What began in 1995 has continued through to today, and we're on the cusp of some new changes that add even more complexity.

Every single piece of our world has grown. The Vista operating system is now so complex that it isn’t realistic to understand the entire platform – especially when we’re expected to also know Windows XP and Server 2003 and probably still Windows 2000.

For many of us, the .NET Framework has replaced the operating system as a point of focus. Who cares about Windows when I’ve got .NET. But the .NET Framework is now well over 10,000 classes and some totally insane number of methods and properties. It is impractical to be an expert on all of .NET.

Below the operating system and .NET, the hardware is undergoing the first meaningful change in 20 years: from single processor to multiple processors and/or cores. Yes, I know multiprocessor boxes have been around forever – our VAX was dual CPU in 1989. But we are now looking at desktop computers having dual core standard. Quad core within a couple years.

(I know most people went from 16 to 32 bits – but the VAX was 32 bit when I started, and 64 bit when I moved to Windows, so I can’t get too excited over how many bits are in a C language int. After you've gone back and forth on the bit count a couple times it doesn't seem so important.)

But this dual/quad processor hardware isn’t uniform. Dual processor means separate L1/L2 caches. Dual core means separate L1, but sometimes combined L2 caches. AMD is working on a CPU with a shared L3 cache. And this actually matters in terms of how we write software! Write your software wrong, and it will run slower rather than faster, thanks to cache and/or memory contention.

(This sort of thing, btw, is why understanding the actual OS is so important too. The paging model used by OpenVMS and Windows can have a tremendous positive or negative impact on your application’s performance if you are looping through arrays or collections in certain ways. Of course Vista changes this somewhat, so yet again we see expansion in what we need to know to be effective…)

At least now we only have one real programming language: VB/C# (plus or minus semi-colons), though that language keeps expanding. In .NET 2.0 we got generics, in 3.5 there’s a whole set of functional language additions to support LINQ. And I’m not even mentioning all the little tweaky additions that have been added here and there – like custom events in VB or anonymous delegates in C#.

And how many of us know the .NET “assembly language”: CIL? I could code in the VMS macro assembly language, but personally I struggle to read anything beyond the simplest CIL…

I could belabor the point, but I won’t. Technology staples like SQL Server have grown immensely. Numerous widely used frameworks and tools have come and gone and morphed and changed (Commerce Server, SharePoint, Biztalk, etc).

The point is that today it is impossible for a developer to be an expert in everything they need to use when building many applications.

As I mentioned at the beginning, I’ve been spending a lot of time in hospitals. And so I’ve interacted with a lot of nurses and doctors. And it is scary. Very, very scary.

Why?

Because they are all so specialized that they can’t actually care for their patients. As a patient, if you don’t keep track of what all the specialists say and try to do to you, you can die. An oncologist may prescribe treatment A, while the gastro-intestinal specialist prescribes treatment B. And they may conflict.

Now in that simple case, the specialists might (might!) have collaborated. But if you are seriously ill, you can easily have 4-8 specialists prescribing treatments for various subsystems of your body. And the odds of conflict is very high!

In short, the consumer (patient) is forced to become their own general physician or risk serious injury or death at the hands of the well-meaning, but incredibly-specialized physicians surrounding them.

And I think this is where our industry is headed.

I know people who are building their entire career by specializing on TFS, or on SharePoint Server, or on SQL Server BI technologies, or Biztalk. And I don’t blame them for a second, because there’s an increasing market demand for people who have real understanding of each of these technologies. And if you want to be a real expert, you need to give up any pretense of expertise in other areas.

The same is true with the Windows/Web bifurcation. And now WPF is coming on the scene, so I suppose that’s a “trifurcation”? (apparently that’s a real word, because the spell checker didn’t barf!)

What amazes me is that this insane explosion in complexity has occurred, and yet most of my customers still want basically the same thing: to have an application that collects and processes data, generates some reports and doesn’t crash.

But I don’t think this trend is reversible.

I do wonder what the original OO people think. You know, the ones who coined the “software crisis” phrase 20 or so years ago? Back then there was no real crisis – at least not compared to today…

So what does this mean for us and our industry?

It is an incredible shift for an industry that is entirely built on generalists. Companies are used to treating developers like interchangeable cogs. We know that’s bad, but soon they will know it too! They’ll know it because they’ll need a bigger staff, and one that has more idle time per person, to accomplish things a single developer might have done in the past.

Consulting companies are built on utilization models that pre-suppose a consultant can fill many roles, and can handle many technology situations. More specialization means lower utilization (and more travel), which can only result in higher hourly rates.

Envision a computer industry that works like the medical industry. “Developers” employed in corporate settings become general practitioners: people who know a little about a lot, and pretty much nothing about anything. Their role is primarily to take a guess about the issue and refer the customer to a specialist.

These specialists are almost always consultants. But those consultants have comparatively low utilization. They focus on some subset of technology, allowing them to have expertise, but they’re largely ignorant of the surrounding technologies. Because their utilization is low, they are hopping from client to client, never focused entirely an any one – this reduces their efficiency. Yet they are experts, and they are in demand, so they command a high hourly rate – gotta balance the lower hours somehow to get the same annual income…

Many projects require multiple specialists, and the consumer is the only one who knows what all is going on. Hopefully that “general practitioner” role can help – but that’s not the case in the medical profession. So we can extrapolate that in many cases it is the end consumer, the real customer, that must become tech-savvy enough to coordinate all these specialists as they accidentally conflict with each other.

Maybe, just maybe, we can head this off somewhat. Maybe, unlike in the medical industry, we can develop generalists as a formal role. Not that they can directly contribute much to the effort, but at least the people in this role can effectively coordinate the specialists that do the actual work.

Just think. If each cancer patient had a dedicated general practitioner focused on coordinating the efforts of the various specialists, how much better would the results be? Of course, there’s that whole issue of paying for such a dedicated coordinator – somehow who’s continuing education and skills would have to be extraordinary…

Then again, maybe I’m just being overly gloomy and doomy. Maybe we’ll rebel against the current ridiculous increases in complexity. Maybe we’ll wake up one day and say “Enough! Take this complexity and shove it!”

A few months ago I blogged about Paul Sheriff's experiment with selling content on the web, though something he calls the Inner Circle.

Like all such experiments, there are lessons to be learned. And any good experiment will evolve over time based on feedback and observation. Recently, Paul changed his pricing model from a recurring subscription, to a one-time fee for a lifetime membership. While I know a fair number of people did go for the subscription model, I think Paul decided to continue the experiment by trying a different model, and this is it.

I know Paul recently put a framework for accessing data, configuration settings, cryptography, exception handling and key management online there, so he's not only doing articles and webcasts, but is providing code and components as well.

If you were leery of the recurring subscription model, you might want to take another look and see if this new model fits you better.

Dunn Training has done a great job with the CSLA .NET 3 day training class, and the feedback so far has been very positive!

The release version of CSLA .NET version 2.1.4 is now available for download from www.lhotka.net/cslanet/download.aspx.

This version addresses a set of ongoing issues with the CslaDataSource control for web development. Thanks to Andrés Villanueva, who put in a lot of work, the control is now able to find business types reliably as you rebuild your solution over time. Additionally, you can now put business classes directly in your web project and use them (though I don't encourage this, as it breaks down good layering of your application).

Other than the changes to CslaDataSource, version 2.1.4 is documented by the CSLA .NET Version 2.1 Handbook available from http://store.lhotka.net, and of course by my Expert C# 2005 Business Objects and Expert VB 2005 Business Objects books.

I get a lot of questions about the new ADO.NET Entity Framework and LINQ and how these technologies interact with CSLA .NET. I've discussed this in a few other blog posts, but the question recently came up on the CSLA .NET forum and I thought I'd share my answer:

They are totally compatible, but it is important to remember what they are for.

Both ADO.NET EF and LINQ work with entity objects - objects designed primarily as data containers. These technologies are all about making it an easy and intuitive process to get data into and out of databases (or other data stores) into entity objects, and then to reshape those entity objects in memory.

CSLA .NET is all about creating business objects - objects designed primarily around the responsibilities and behaviors defined by a business use case. It is all about making it easy to build use case-derived objects that have business logic, validaiton rules and authorization rules. Additionally, CSLA .NET helps create objects that support a rich range of UI supporting behaviors, such as data binding and n-level undo.

It is equally important to remember what these technologies are not.

ADO.NET EF and LINQ are not well-suited to creating a rich business layer. While it is technically possible to use them in this manner, it is already clear that the process will be very painful for anything but the most trivial of applications. This is because the resulting entity objects are data-centric, and don't easily match up to business use cases - at least not in any way that makes any embedded business logic maintainable or easily reusable.

CSLA .NET is not an object-relational mapping technology. I have very specifically avoided ORM concepts in the framework, in the hopes that someone (like Microsoft) would eventually provide an elegant and productive solution to the problem. Obviously solutions do exist today: raw ADO.NET, , the DAAB, nHibernate, Paul Wilson's ORM mapper, LLBLgen and more. Many people use these various technologies behind CSLA .NET, and that's awesome.

So looking forward, I see a bright future. One where the DataPortal_XYZ methods either directly make use of ADO.NET EF and LINQ, or call a data access layer (DAL) that makes use of those technologies to build and return entity objects.

Either way, you can envision this future where the DP_XYZ methods primarily interact with entity objects, deferring all the actual persistence work off to EF/LINQ code. If Microsoft lives up to the promise with EF and LINQ, this model should seriously reduce the complexity of data access, resulting in more developer productivity - giving us more time to focus on the important stuff: object-oriented design ;) .

I have a custom data source control as part of my CSLA .NET framework. It is somewhat like ObjectDataSource, but works with objects that are created through factory methods rather than default constructors (and some other variations).

All is pretty well with this control, except one issue: it fails when adding a CslaDataSource control to a page as a new data source from a DetailsView or other control.

In other words, you add a DetailsView to the page, then tell that control you want it to bind to a new data source and it brings up a wizard, where you pick CslaDataSource so a new one is added to the page.

The problem I’m getting is a VERY odd exception: Csla.Web.CslaDataSource can not be cast to Csla.Web.CslaDataSource.

Yes, that’s right – the type can’t be cast to itself.

I believe this is because the wizard is loading its own copy of Csla.dll into memory, separate from the one used by the web forms designer. Or something like that. This even confuses the debugger – it can’t show details about the type because it says the type is loaded into two different GUIDs. I don’t know what the GUIDs represent (appdomains, versions?), but it is obviously not good.

This is very weird, and after hours of time on this, I’m quite stumped. Any help, clues, pointers or ideas are VERY welcome!

Thanks! Rocky

It seems that people are always looking for The Next Big Thing™, which isn’t surprising. What I do find surprising is that they always assume that TNBT must somehow destroy the Previous Big Thing™, which in the field of software development was really object-orientation (at least for most people).

Over the past few years Web Services and then their reincarnation as SOA or just SO were going to eliminate the use of OO. As more and more people have actually implemented and consumed services I think it has become abundantly clear that SOA is merely a repackaging of EAI from the 90’s and EDI from before that. Useful, but hardly of the sweeping impact of OO, at least not in the near term.

Though to be fair, OO took more than 20 years before it became remotely “mainstream”, and even today only around 30% of developers (based on my informal, but broad, polling over the past couple years) apply OOD in their daily work. So you could question whether OO is “mainstream” even today, when the vast majority of developers use procedural programming techniques.

Even though the majority of .NET and Java developers don’t actually use OO themselves, both the .NET and Java platforms are OO throughout. So there’s no doubt that OO has had an incredible impact on our industry, and that it has shaped the major platforms and development styles used by almost everyone.

So perhaps in 15-20 years SO really will have the sweeping impact that OO has had on software development. And I’m not sure that would be a bad thing, but it isn’t a near-term concern.

However, I was recently confronted by a (so-called) newcomer: workflow. Yes, now workflow (WF) is going to kill OO, or so I’ve been told. In fact, Through indirect channels, my challenger suggested that the CSLA .NET framework is obsolete going forward because it is based on these “old-school” OO concepts.

Obviously I beg to differ :)

It is true that some of the concepts I employ in CSLA .NET are quite old, but I am not ready to through OO into the “old-school” bucket just yet... The idea is somewhat ironic however, because WF is being put up as The Next Big Thing™. Depressingly, there's virtually no technology today that isn't a rehash of something from 20 years ago. That's more true of SOA and WF than OO. Remember that SOA is just repacking of message-based architecture, only with XML, and workflow is an extension of procedural design and the use of flowcharts. At least OO can claim to be younger than either of those two root technologies.

Personally, I very much doubt the use of objects as rich behavioral entities will go away any time soon. Sure, for non-interactive tasks procedural technologies like WF might be better than OO (though that's debatable). And certainly for connecting disparate systems you need to use loosely coupled architectures, of which SOA is one (but not the only one).

But the question remains: how do you create rich, interactive GUI applications in a productive and yet maintainable manner?

Putting your logic in a workflow reduces interactivity. Putting your logic behind a set of services reduces both interactivity and performance. Putting your logic in the UI is "VB3 programming". So what's left? For interactive apps you need a business layer that can run as close to the user as possible and using business objects is a particularly good way to do exactly that.

Neither WF nor WCF/SOA are, to me, competitors to CSLA. Rather, I see them as entirely complimentary.

Perhaps ADO.NET EF and/or LINQ are competitors - that depends on what they look like as they stabilize over the next several months. Everything I’ve seen thus far leads me to believe these technologies are complimentary as well. (And Scott Guthrie agrees – check out his recent interview on DNR) Neither of them addresses the issues around support for data binding, or centralization of business logic in a formal business layer.

But when it comes to SOA I still think it is a “fad”. It is either MTS done over with XML - which is what 95% of the people out there are doing with "services", or it is EDI/EAI with XML - which is a good thing and a move forward, but which is too complex and has too much overhead for use in a typical application. I think that most likely in 5-10 years we'll have a new acronym for it – just adding to the EDI/EAI/SOA list.

Just like "outsourcing" became ASP which became SaaS. The idea doesn't die, it just gets renamed so more money can be made by selling the same stuff over again - often to people who really don't need/want it.

The point is, our industry is cyclical. And we're heading toward into a period where "procedural programming" is once again reaching a peak of usage. This time under the names SOA and workflow. But if you step back from the hype and look at it, what's proposed is that we create a bunch of standalone code blocks that exchange formatted data. A set of procedures that exchange parameters. Dress it up how you like, that's what is being proposed by both the SOA and WF crowds.

And there's nothing wrong with that. Procedural design is well understood.

And it could actually work this time around if we don't cheat. I still maintain that the reason procedural programming "failed" was because we cheated and used common blocks and global variables. Why? Because it was too inefficient and required too much code to formally package up all the data and send it as parameters.

If we can stomach the efficiency and coding costs this time around - packing the data into XML messages - then I see no reason why we can't make procedural programming work in many cases. And by naming it something trendy, like SOA and/or workflow, we can avoid the negative backlash that would almost certainly occur if people realized they were abandoning OO to return to procedural programming.

Having spent the first third of my career doing procedural programming, I wouldn't necessarily mind going back. In some ways it really was easier than using objects - though there are some very ugly traps that people will have to rediscover again on this go-round. Most notably the trap that a procedure can't be reused without introducing fragility into the system, not due to syntactic coupling or API changes, but due to semantic coupling (about which I've blogged).

This is true for procedures and any other "reusable" code block like a workflow activity or a service. They all suffer the same limitation - and it is one that neither WSDL nor compilers can help solve...

Anyway, kind of went on a rant here - but I find it amusing that, in some circles at least, OO is viewed as the "legacy" technology in the face of services or workflow, which are even more legacy than OO ;)

Dunn Training has scheduled the next CSLA .NET class for Feb 26-28 in Atlanta. Feedback from the classes thus far has been very positive, for example:

From Dave Boal from Denver, CO:

I need to thank you once again for getting me committed to CSLA. I have always been interested in CSLA, but in the past, never actually made it to the point of applying the technology. I have never took the time required to understand, let alone evaluate the technology. Your course and enthusiasm, combined with chapters 6-8 of Rocky's book, burst me through this evaluation barrier in just 7 days, something I did not think was possible in less than 3 months.

If you want to get a quick, solid, start using CSLA .NET I recommend you consider Dunn Training's class.

The CSLA .NET Version 2.1 Handbook is available NOW at http://store.lhotka.net for both C# and VB.

Additionally, version 2.1.3 of CSLA .NET is now available for download from this location.

Version 2.1.3 includes some bug fixes and minor enhancements. The enhancements are primarily around the CslaDataSource web control, which now provides more integrated support for paging and sorting.

Most importantly, version 2.1.3 is the specific version described in my CSLA .NET Version 2.1 Handbook. I am releasing this as a ~160 page ebook, available in editions for both C# and VB, for purchase directly from my web site.

This new book is best thought of as a sequel to my my Expert C# 2005 Business Objects and Expert VB 2005 Business Objects books. It covers the changes made since CSLA .NET 2.0 was released: how the framework has changed, and how to use the new features and capabilities. Please note that this is not a replacement for those books: it expands on them.

I hope you enjoy CSLA .NET 2.1.3, and the new book. Thank you, code well, have fun!