Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

Searched for : meme

I was just at a family reunion and heard a joke about the comedian’s retirement home. A guy walks into the common room and hears one old guy shout out “19”, and everyone laughs. Across the room another guy shouts out “54” and everyone laughs even harder. The guy turns to his guide and asks “What is going on?”. The guide replies “These guys know all the same jokes, and at their age it takes too long to tell them, so they just assigned them all numbers.” The guy smiles, and shouts out “92”, which results in a just a few grudging chuckles. “What’d I do wrong?” he asks the guide. The guide replies “Some people can tell a joke, some people can’t.”

That made me think about patterns (yes, I know, I’m a geek).

I like design patterns. Who wouldn’t? They are a formalized description of a solution to a specific problem. If you have that problem, then having a formally described solution seems like a dream come true.

Perhaps more importantly patterns are a language short-cut. If everyone in a conversation understands a pattern, the pattern (and often its problem) can be discussed merely by using the pattern name, which saves an immense amount of time as opposed to describing the actual problem and solution in detail.

Of course the “formalized description” is prose. Human language. And therefore it is ambiguous and open to interpretation. The descriptions must be human-readable, because any pattern worth ink and paper transcends any specific platform or programming language. Describing a “pattern” in Java or C# is silly – because that makes it far too likely that it isn’t really a broad pattern, but is simply a practice that happens to work in a given language or on a given platform.

But this ambiguity leads to trouble. Not unlike the comedian’s retirement home, patterns are a short-cut language to some really complex concepts, and often even more complex implementations. While everyone might have a basic comprehension of “inversion of control”, I can guarantee you that saying IoC doesn’t bring the same concept, implementation or emotional response from everyone who hears it.

Pattern zealots often forget (or overlook) the fact that patterns have consequences. Good and bad consequences. Every pattern has bad consequences, as well as good ones. Some people get attached to a pattern because it helped them at some point, and they just assume that pattern will always have a positive or beneficial result. But that’s simply not true. Sometimes the negative consequences of a pattern outweigh the positive – it is all very dependent on the specific problem domain and environment.

Soft things like staffing levels, skill sets, attitudes and time frames all enter into the real world environment. Add the reality that any given problem almost certainly has several patterns that provide solutions – for different variations of the problem – and it becomes clear that no one pattern is always “good”.

It should come as no surprise then, that patterns are often misused – in several different ways.

My pet peeve is when a pattern is applied because something likes the pattern, not because the application actually has the problem the pattern would solve. I often see people using IoC, for example, because it is trendy, not because they actually need the flexibility provided by the pattern. They use a container to create instances of objects that they will never swap out for other implementations. What a waste – they’ve accepted all the negative consequences of the pattern for absolutely no benefit since they don’t have the problem the pattern would solve. Is this the fault of IoC? Of course not, IoC is a powerful pattern.

It is the fault of what I call the “Pattern Of The Year” (POTY) syndrome. When a pattern becomes really popular and trendy, it becomes the POTY. And everyone wants to go to the POTY. If you need the POTY, you should go. But if you don’t need the POTY, it is really a little silly (if not creepy) for you to go to the POTY…

In short: only use a pattern if you have the problem it solves, and the positive consequences outweigh the negative consequences.

Perhaps the most common misuse of patterns is failure to actually understand the pattern or its implementation. To stick with IoC as an example, it is pretty common for a development team to completely misunderstand the pattern or the framework that implements the pattern. Sure, some architect or lead developer “got it” (or so we hope) which is why the team is using the pattern – but you can find apps where numerous competing containers are created, each initialized differently.

I always thought Apple BASIC spaghetti code was the worst thing possible – but misuse of certain design patterns quickly creates a mess that is an order of magnitude worse than anything people wrote back in the early 80’s…

In short: if you use a pattern, make sure your entire team understand the pattern and your implementation of the pattern.

As I mentioned earlier, most problems can be solved by more than one pattern. Any truly interesting problem almost certainly has multiple solutions, each with different good/bad consequences and various subtle differences in outcome. It is not uncommon for the best solution to be a combination of a few more basic patterns.

As an example, the CSLA data portal is a combination of around six basic design patterns that work together in concert to solve the problem space the data portal targets. I’m not saying the data portal is a design pattern, but it is a solution for a problem that came into being by combining several complimentary patterns.

A few years after I created the data portal, various other design patterns were formalized that describe other solutions to this same problem space. Some are similar, some are not. If you look into each solution, it is clear that each one is actually a different combination of some lower level design patterns, working together to solve the problem.

The thing is, every pattern your bring into your solution (or ever pattern brought in by a higher level pattern) comes with its own consequences. You need to be careful to minimize the negative consequences of all those patterns so the overall balance is toward the positive.

In short: don’t be afraid to combine simple or basic design patterns together to solve a bigger problem, but be aware of the negative consequences of every pattern you bring into play.

Having introduced this concept of “low level” vs “high level” patterns, I’m going to follow that a bit further. Most of the patterns in the original GoF book are what I’d call low level patterns. They stand alone and have little or no dependency on each other. Each one solves a very narrow and clear problem and has very clear good/bad consequences.

Of course that was 15 years ago, and since then people have applied the pattern concept to more complex and bigger problem spaces. The resulting solutions (patterns) very often build on other patterns. In other words we’re raising the level of abstraction by building on previous abstractions. And that’s a fine thing.

But it is really important to understand that ultimately patterns are implemented, and the implementations of patterns are often far messier than the abstract though models provided by the patterns themselves. Even that is OK, but there’s a meta-consequence the flows out of this: complexity.

As you start to use higher level patterns, and their implementations, you can easily become locked into not only the implementation of the pattern you wanted, but also the implementations of the lower level patterns on which the implementation is built.

Again I’ll use IoC to illustrate my point. If you want IoC you’ll almost certainly use a pre-existing implementation. And once you pick that framework, you are stuck with it. You won’t want to use more than one IoC framework, because then you’d have multiple containers, each configured differently and each competing for the attention of every developer. The result is a massive increase in complexity, which means a reduction in maintainability and a corresponding increase in cost.

Now suppose you pick some higher level pattern, perhaps a portal or gateway, that is implemented using IoC. If you want the implementation of the gateway pattern you must also accept a dependency on their IoC framework choice.

People often ask me whether (or when will) CSLA .NET will incorporate Enterprise Library, log4net, Unity, Castle/Windsor, <insert your framework here>. I try very, very, very hard to avoid any such dependencies, because as soon as I pick any one of these, I make life really hard for everyone out there who didn’t choose that other framework.

CSLA 3.8 has a dependency on a simple data structure framework, and even that was a continual nightmare. I can hardly express how happy I am that I was able to get rid of that dependency for CSLA 4. Not that the data structure framework was bad – it does a great job – but the complexity introduced by the dependency was just nasty.

In short: be aware of the complexity introduced as high level patterns force you to accept dependencies on lower level patterns and implementations.

The final topic I’d like to cover flows from a conversation I had with Ward Cunningham a few years ago. We were talking about patterns and the “pattern movement”, and how it has become a little warped over time as people actively look for ways to apply patterns, rather than the patterns being used because they are the natural answer to a problem.

It is kind of like a carpenter who spends a lot of money buying some really nice new power tool. And then trying to use that power tool for every part of the construction process – even if that means being less efficient or increasing the complexity of the job – just to use the tool.

Obviously I’d never want to hire such a carpenter to work on my house!!

Yet I’ve seen developers and architects get so fascinated by specific patterns, frameworks or technologies that they do exactly that: increase the complexity of simple problem domains specifically so they can use their new toy concept.

In this conversation Ward suggested that there are different levels of understanding or mastery of patterns. At the most basic level are people just learning what patterns are, followed by people who “get” a pattern and actively seek opportunities to use that pattern. But at higher levels of mastery are people who just do their job and (often without a conscious thought) apply patterns as necessary.

Carpenters don’t think twice about when and how to construct a staircase or put together a 2x6” wall frame. These are common design patterns, but they are natural solutions to common problems.

In short: strive for “pattern mastery” where you are not fixated on the pattern, but instead are just solving problems with natural solutions, such that the pattern “disappears” into the fabric of the overall solution.

The pattern movement has been going on for at least 15 years in our industry. And over that time I think it has been far more beneficial than destructive.

But that doesn’t mean (especially as a consultant) that you don’t walk into many organizations and see horrible misuse of design patterns – the results being higher complexity, lower maintainability and higher cost of development and maintenance.

I think it is important that we continually strive to make patterns be a common abstract language for complex problems and solutions. And I think it is important that we continually educate everyone on development teams about the patterns and implementations we bring into our applications.

But most importantly, I think we need to always make conscious choices, not choices based on trends or fads or because somebody on the team is in love with pattern X or framework Y or technology Z.

  1. Use a pattern because you have the problem it solves
  2. Only use a pattern if the good consequences outweigh the bad (and remember that every pattern has negative consequences)
  3. Use patterns and implementations only if the entire team understands them
  4. Use the simplest pattern that solves your problem
  5. Don’t be afraid to combine several simple patterns to solve a complex problem
  6. Be aware of (and consciously accept) the consequences of any low level patterns that come with most high level pattern implementations
  7. Strive for “pattern mastery”, where you are solving problems with natural solutions, not looking for ways to apply any specific pattern

Eventually maybe we’ll all be in a software development retirement home and we can shout things like “Memento” and “Channel adaptor” and everyone will chuckle with fond memories of how those patterns made our lives easier as we built the software on which the world runs.

Monday, 19 July 2010 11:03:04 (Central Standard Time, UTC-06:00)  #    Disclaimer

Bil Simser tagged me with this meme, thanks Bil.

As I tend to do with these things, I'll answer, but I'm not going to pass it on.

Apparently the idea is to list 5 things that'll make me a better developer over the next 6 months. The problem is, I'm not sure being a better developer is my primary focus just at the moment. But here's my list:

Keep my head above water

Microsoft has recently, and continues into the foreseeable future, to come out with new technology releases at a ridiculous pace. By "head above water" all I really mean is that I want, at least, to have a general clue about the purpose and real capabilities of all the stuff they are throwing at us. Not just the marketing hype, but what it really means. This, to me, has always been one of my primary strengths: the ability to grok most of the technologies available, and to figure out how they fit into some overarching architecture/worldview/philosophy.

But the current rate of change, and the amount of redundancy (ADO.NET, DataSets, LINQ, ADO.NET EF all solving the same problem? Come on!) makes this increasingly challenging. So over the next 6 months I'll be reading, talking to experts (and anyone else with something to offer) and experimenting in the hopes of keeping my head above water.

CSLA .NET

I used to learn new technologies by writing games - specifically MUDs and then low-end MMORPGs (well, I wrote and rewrote parts of one that never really came together). Someday I'd like to get back to doing that.

But in the meantime, I have CSLA .NET, and it has grown enough over the years that it affords me the opportunity to explore most of the key technologies I really want to learn. Having just released version 3.0, I got to dig into the plumbing behind WPF data binding, and explore the details around how WCF supports client/server (which it does well btw). Now my sights are turned toward two targets: .NET 3.5 and Silverlight.

The new language features, and of course lINQ itself, are key areas of focus for CSLA .NET 3.5. Fun stuff, no doubts there!

And if Silverlight 1.1 gets just a few more features (most notably data binding to objects), I believe I can create a CSLA Light that will provide a meaningful subset of CSLA .NET functionality within the Silverlight environment. If that pans out, it will be quite exciting :)

Magenic

Working for Magenic is great! I really enjoy the company and the people I work with. Over the next few months I'll be conciously spending more time and energy working internally with Magenic. As noted above, Microsoft's technology release schedule is grueling, and I want to make sure Magenic's consultants have the opportunity to stay on top of everything. This not only means doing some internal training, but more importantly working to build up a base of expertise and the infrastructure so other people can do some of that training (formally or informally).

It is (in my view) entirely unrealistic for one person to be an expert on everything that's going on. How can you credibly span .NET, Windows, Web, AJAX, SOA, Silverlight, SharePoint, Biztalk, SQL, Windows Server 2008 and everything else? You can't. But Magenic can, because we have a large enough pool of people that there's a decent level of expertise in all these technologies spread across the company. My challenge, then, is to coordinate that expertise such that the experts are in a position to share their knowledge with everyone else who needs it.

Of course Magenic has five offices across the country, and so there's the interesting sub-challenge of enabling the sharing of expertise across geographic distance. Actually it isn't the knowledge sharing that's such a big deal (we have great forums, etc), but it is the sharing if passion that is harder - and yet is at least as important.

Don't burn out

I've been feeling seriously burned out of late. That's not good. Part of it is due to the way travel grates on me more all the time, but most of it is that I haven't spent time doing truly exploratory things for a very long time now. CSLA has become quite consuming, and so my spare time goes into the framework, when I could be working on a .NET MUD engine or something really fun like that (I have these cool prototypes for truly dynamic world behavior that I'd love to pull together into something real).

It is also the case that I'm terrible about taking vacations. If I vacation at home, I work. That's the primary drawback with having a home office - work is always right there. But with Smartphones and laptops with wireless and/or cell modems the "office" can go almost anywhere, so even with a traditional office, escape is almost impossible.

Except... In August I'm spending a full week (nearly 10 days) in or near the Boundary Waters in far northern Minnesota. No meaningful cell coverage, no Starbucks or anywhere like it that would have wireless. Just untold miles and miles of wilderness, canoing, camping and fishing. Yea!

Remember the passion

Have you ever played that "what if" game? The one where you ask youself what job you'd do if you didn't do your current job?

I always draw a blank. If I had to do something else it would actually be work, rather than what I do now, which is to get paid for my hobby.

This, by the way, is what bothers me most about outsourcing, or even the software factory concept. It is true that economic needs shift over time, and steel workers needed to get new skills to find new jobs (as an example). I suppose it is possible that many of those steel workers had a burning passion for their job. That working with steel was their hobby as well as their job. But I doubt it. Most people I know view work as work: as a way to make money so they can do what they really want to do in their off hours. On the other hand, most developers I know view work as fun - and a way to make money while having fun.

Economists are often dismissive toward us, saying that if our jobs go offshore that we can just learn new skills and find different jobs. What they fail to understand is that we'd be doing far more than switching jobs: we'd be giving up an entire way of life. We'd be moving from a world of creative inspiration to a world of soul-crushing tedium. Yes, I realize I'm probably being very condenscending toward people with "normal" jobs, but this is how I see the world... (Then again, maybe economists do realize the deep love we have for what we do, and they envy us and so feel no remorse in talking about the destruction of our way of life?)

In any case, I love aspects of technology (especially building distributed and/or quasi-autonomous systems). And I love teaching about development. These things have been my passion since long before I officially started my career (when I was just a teenager, I was teaching elementary school kids how to use those new-fangled computers (Apples with no floating point support)). And I love writing - I really am what JMS describes as an "author" (one cursed to write because they can't not write). I can't imagine not doing most of the things I do today.

I think that's the key: remember the passion. Remember the fun. Yes, work hard, but more importantly code well, and perhaps above all: have fun!

Thursday, 12 July 2007 10:38:00 (Central Standard Time, UTC-06:00)  #    Disclaimer

There's this "five things about me" tagging meme going around, and I've now been tagged by Bill, Craig and Andrea.

1. I grew up in the middle of Minnesota, surrounded by hundreds of acres of forest and lakes. Our nearest neighbor was a mile away. The nearest town 14 miles away, and the nearest real town over 30 miles away. The nearest city: a 2.5 hour drive. As a youth, I lived one of those lives of adventure you might read about from long in the past. I spent my time fishing, hunting, trapping, snowmobiling, boating, swimming and generally wandering through the woods and lakes of central Minnesota.

2. I love alternative metal and alternative rock. Rush, Queensryche, Godsmack, Linkin Park and so forth. Good rock, to me, requires thought-provoking lyrics, evocative sound and serious riffs!

3. I love speculative fiction (the fancy name for science fiction and fantasy). Tolkien, Asimov, Niven, Reynolds, Scalzi, McKillip, Norton and many others are on my favorites list. Between all these books, and my wife's collection of all the essays, letters and other writings of America's founding fathers (plus many random other books on many topics) we have an entire room set aside as a library.

4. My first overseas trip was to London, to attend a Babylon 5 convention to commemorate the conclusion of the show. My wife was (and technically still is) a moderator on the Babylon 5 moderated newsgroup (remember usenet? :) ).

5. I'm a would-be game developer. Years ago I wrote a MUD for the DEC VAX called Mordecai. It consumed all the resources the university VAX could muster back then, and I even ended up working with the Operations guys to build in capabilities to throttle the game so it wouldn't be playable during prime homework usage periods and that sort of thing. I've written bits and pieces of a much more ambitious .NET equivalent, but that project stalled a while back. The reality today is that game development is such a small part of building a game in total (graphics, physics engines and so forth are a much bigger part) that it is hard to get as excited about this stuff as I used to be...

Kindly enough, and because I don't have time to track down who's been tagged or not, I'm not tagging anyone, so this thread of execution ends here ;)

Wednesday, 24 January 2007 19:44:48 (Central Standard Time, UTC-06:00)  #    Disclaimer

There’s a thread on the CSLA .NET discussion forum about possible differences between the VB and C# versions of CSLA .NET. I started to answer the thread, then got on a roll, so it became a blog entry :-)

 

I strive to keep the two versions of CSLA .NET in sync within a reasonable time window. Everything after version 1.0 (the version in my books) is essentially my donation to the community. What I get out of it is not wealth, but rather is a lot of very interesting and useful feedback from the vibrant CSLA .NET community. I'm able to try out some of the most interesting (to me) ideas by releasing new and updated versions of the code. It is a learning opportunity.

 

The fact that I have to do every mod twice is a serious pain and does reduce the fun, but I think it is worth the pain because it makes the end result more useful for everyone.

 

I do most of my first-run coding in VB, because I prefer it. Simple personal preference. I've done some first-run coding in C# too, I just don't find it as enjoyable. Some people have the reverse experience and that's cool too. That doesn't bother me one way or the other. I fully understand feeling an affinity toward a specific language. It took me years to get over Pascal. Ahh VAX Pascal, I still harbor such fond memories.

 

But what I am more concerned about in terms of CSLA .NET is VS 2005. In .NET 2.0 we start to see some feature divergence between VB and C#. Most notably the My namespace in VB. Fortunately by playing in the middle-tier, CSLA is less subject to the differences than some code will be. However, there'll still be some differences that will make my dual life harder.

 

The biggest one that will impact me is My.Resources, which makes the use of resources somewhat simpler than C#. This isn't a huge thing, but it does mean there'll be extra code differences to reconcile between the two versions in CSLA .NET 2.0.

 

There's also My.Settings, though I don't know if that will impact me quite as much. I anticipate dropping the DB() function from BusinessBase in 2.0, since most people (rightly) avoid putting db connection strings in their config files.

 

The two primary C# features (yield and anonymous delegates) don't appear to have a home in CSLA, so I don't expect any differences from them. Not that they aren’t seriously cool features, but they just don’t have a place in CSLA .NET itself.

 

The new strongly typed TableAdapter classes are very cool. They are useful in both languages. And I hope to use strongly typed TableAdapter objects to simplify the code in the DataPortal_xyz methods.

 

There are some features that are more accessible to VB than C# in the new strongly typed DataTable (due to C#'s lack of WithEvents functionality - a major oversight imo). However, I don't expect to use any of those features in CSLA to start with, so there's no impact there.

 

When I write the book I'll create Windows and Web UI chapters. Those are what I dread most, because that's where the differences due to My become much more serious. There are numerous examples of UI development where My will be a serious code-saver - thus causing direct differences between the VB and C# code. Not that I can't do the same stuff in C#, just that it will take more and different code, which increases the effort on my part as an author.

 

Fortunately most of the book is about the framework and creating business objects, and the language divergence will have relatively minimal impact in those areas.

 

It is hard to speculate on what comes after VS 2005, but personally I expect more divergence, not less. Earlier in the thread someone noted that things like the Mac, Linux and Java still exist even though you can technically do everything they do with Windows and .NET.

 

The fact is that they all serve a purpose, as does .NET to them. People deep in C# often think different than those deep in VB. People in Java think different than those in .NET. This means they have different perspectives, different priorities, on the same problems and issues. This is only good. This means there are competing ideas that we can all evaluate and use to the best of our abilities, regardless of the language or platform we choose to use.

 

Loving distributed computing as I do, I am constantly taking ideas from the C++ and Java worlds. I closely watch the SOA world, even though I think it is misguided in many ways, because there are interesting ideas and perspectives there that can apply to distributed object-oriented systems as well.

 

I’ve said it before and I’ll say it again, if you only know one programming language family (such as the C family or the Basic family) then you really, really need to get out more. Your horizons and thus your career are simply too limited and you can’t be considered credible in most of these discussions.

 

That’s an interesting meme. Which programming languages have you been competent in during your career? I’ll start (in rough order of usage):

 

1.      Apple BASIC

2.      VAX Pascal

3.      Turbo Pascal

4.      DCL

5.      FORTRAN 90

6.      VAX Basic

7.      ARexx

8.      Modula-II

9.      Visual Basic (1-6)

10.  Visual Basic .NET

11.  C#

 

While I did write a VT terminal emulator in C once, I don’t think I was ever really competent in C, so I’m not counting that. My memories of that experience are not inspirational in the slightest… I’ve also dabbled in various Unix shell languages and bat files, but was never competent in them.

 

Converting the list to language families is harder, because things like ARexx aren’t obvious, but here’s my attempt:

 

1.      Pascal (Pascals and Modula-II)

2.      Basic (various)

3.      FORTRAN

4.      Scripting (ARexx, DCL)

5.      C (C# and C if you are generous)

 

So, having wandered from the topic of CSLA .NET parity between VB and C# we arrive at what could be a cool meme. Go ahead, comment or blog – what languages and language families have you been competent in during your career?

Monday, 14 February 2005 18:50:22 (Central Standard Time, UTC-06:00)  #    Disclaimer

I was just at a family reunion and heard a joke about the comedian’s retirement home. A guy walks into the common room and hears one old guy shout out “19”, and everyone laughs. Across the room another guy shouts out “54” and everyone laughs even harder. The guy turns to his guide and asks “What is going on?”. The guide replies “These guys know all the same jokes, and at their age it takes too long to tell them, so they just assigned them all numbers.” The guy smiles, and shouts out “92”, which results in a just a few grudging chuckles. “What’d I do wrong?” he asks the guide. The guide replies “Some people can tell a joke, some people can’t.”

That made me think about patterns (yes, I know, I’m a geek).

I like design patterns. Who wouldn’t? They are a formalized description of a solution to a specific problem. If you have that problem, then having a formally described solution seems like a dream come true.

Perhaps more importantly patterns are a language short-cut. If everyone in a conversation understands a pattern, the pattern (and often its problem) can be discussed merely by using the pattern name, which saves an immense amount of time as opposed to describing the actual problem and solution in detail.

Of course the “formalized description” is prose. Human language. And therefore it is ambiguous and open to interpretation. The descriptions must be human-readable, because any pattern worth ink and paper transcends any specific platform or programming language. Describing a “pattern” in Java or C# is silly – because that makes it far too likely that it isn’t really a broad pattern, but is simply a practice that happens to work in a given language or on a given platform.

But this ambiguity leads to trouble. Not unlike the comedian’s retirement home, patterns are a short-cut language to some really complex concepts, and often even more complex implementations. While everyone might have a basic comprehension of “inversion of control”, I can guarantee you that saying IoC doesn’t bring the same concept, implementation or emotional response from everyone who hears it.

Pattern zealots often forget (or overlook) the fact that patterns have consequences. Good and bad consequences. Every pattern has bad consequences, as well as good ones. Some people get attached to a pattern because it helped them at some point, and they just assume that pattern will always have a positive or beneficial result. But that’s simply not true. Sometimes the negative consequences of a pattern outweigh the positive – it is all very dependent on the specific problem domain and environment.

Soft things like staffing levels, skill sets, attitudes and time frames all enter into the real world environment. Add the reality that any given problem almost certainly has several patterns that provide solutions – for different variations of the problem – and it becomes clear that no one pattern is always “good”.

It should come as no surprise then, that patterns are often misused – in several different ways.

My pet peeve is when a pattern is applied because something likes the pattern, not because the application actually has the problem the pattern would solve. I often see people using IoC, for example, because it is trendy, not because they actually need the flexibility provided by the pattern. They use a container to create instances of objects that they will never swap out for other implementations. What a waste – they’ve accepted all the negative consequences of the pattern for absolutely no benefit since they don’t have the problem the pattern would solve. Is this the fault of IoC? Of course not, IoC is a powerful pattern.

It is the fault of what I call the “Pattern Of The Year” (POTY) syndrome. When a pattern becomes really popular and trendy, it becomes the POTY. And everyone wants to go to the POTY. If you need the POTY, you should go. But if you don’t need the POTY, it is really a little silly (if not creepy) for you to go to the POTY…

In short: only use a pattern if you have the problem it solves, and the positive consequences outweigh the negative consequences.

Perhaps the most common misuse of patterns is failure to actually understand the pattern or its implementation. To stick with IoC as an example, it is pretty common for a development team to completely misunderstand the pattern or the framework that implements the pattern. Sure, some architect or lead developer “got it” (or so we hope) which is why the team is using the pattern – but you can find apps where numerous competing containers are created, each initialized differently.

I always thought Apple BASIC spaghetti code was the worst thing possible – but misuse of certain design patterns quickly creates a mess that is an order of magnitude worse than anything people wrote back in the early 80’s…

In short: if you use a pattern, make sure your entire team understand the pattern and your implementation of the pattern.

As I mentioned earlier, most problems can be solved by more than one pattern. Any truly interesting problem almost certainly has multiple solutions, each with different good/bad consequences and various subtle differences in outcome. It is not uncommon for the best solution to be a combination of a few more basic patterns.

As an example, the CSLA data portal is a combination of around six basic design patterns that work together in concert to solve the problem space the data portal targets. I’m not saying the data portal is a design pattern, but it is a solution for a problem that came into being by combining several complimentary patterns.

A few years after I created the data portal, various other design patterns were formalized that describe other solutions to this same problem space. Some are similar, some are not. If you look into each solution, it is clear that each one is actually a different combination of some lower level design patterns, working together to solve the problem.

The thing is, every pattern your bring into your solution (or ever pattern brought in by a higher level pattern) comes with its own consequences. You need to be careful to minimize the negative consequences of all those patterns so the overall balance is toward the positive.

In short: don’t be afraid to combine simple or basic design patterns together to solve a bigger problem, but be aware of the negative consequences of every pattern you bring into play.

Having introduced this concept of “low level” vs “high level” patterns, I’m going to follow that a bit further. Most of the patterns in the original GoF book are what I’d call low level patterns. They stand alone and have little or no dependency on each other. Each one solves a very narrow and clear problem and has very clear good/bad consequences.

Of course that was 15 years ago, and since then people have applied the pattern concept to more complex and bigger problem spaces. The resulting solutions (patterns) very often build on other patterns. In other words we’re raising the level of abstraction by building on previous abstractions. And that’s a fine thing.

But it is really important to understand that ultimately patterns are implemented, and the implementations of patterns are often far messier than the abstract though models provided by the patterns themselves. Even that is OK, but there’s a meta-consequence the flows out of this: complexity.

As you start to use higher level patterns, and their implementations, you can easily become locked into not only the implementation of the pattern you wanted, but also the implementations of the lower level patterns on which the implementation is built.

Again I’ll use IoC to illustrate my point. If you want IoC you’ll almost certainly use a pre-existing implementation. And once you pick that framework, you are stuck with it. You won’t want to use more than one IoC framework, because then you’d have multiple containers, each configured differently and each competing for the attention of every developer. The result is a massive increase in complexity, which means a reduction in maintainability and a corresponding increase in cost.

Now suppose you pick some higher level pattern, perhaps a portal or gateway, that is implemented using IoC. If you want the implementation of the gateway pattern you must also accept a dependency on their IoC framework choice.

People often ask me whether (or when will) CSLA .NET will incorporate Enterprise Library, log4net, Unity, Castle/Windsor, <insert your framework here>. I try very, very, very hard to avoid any such dependencies, because as soon as I pick any one of these, I make life really hard for everyone out there who didn’t choose that other framework.

CSLA 3.8 has a dependency on a simple data structure framework, and even that was a continual nightmare. I can hardly express how happy I am that I was able to get rid of that dependency for CSLA 4. Not that the data structure framework was bad – it does a great job – but the complexity introduced by the dependency was just nasty.

In short: be aware of the complexity introduced as high level patterns force you to accept dependencies on lower level patterns and implementations.

The final topic I’d like to cover flows from a conversation I had with Ward Cunningham a few years ago. We were talking about patterns and the “pattern movement”, and how it has become a little warped over time as people actively look for ways to apply patterns, rather than the patterns being used because they are the natural answer to a problem.

It is kind of like a carpenter who spends a lot of money buying some really nice new power tool. And then trying to use that power tool for every part of the construction process – even if that means being less efficient or increasing the complexity of the job – just to use the tool.

Obviously I’d never want to hire such a carpenter to work on my house!!

Yet I’ve seen developers and architects get so fascinated by specific patterns, frameworks or technologies that they do exactly that: increase the complexity of simple problem domains specifically so they can use their new toy concept.

In this conversation Ward suggested that there are different levels of understanding or mastery of patterns. At the most basic level are people just learning what patterns are, followed by people who “get” a pattern and actively seek opportunities to use that pattern. But at higher levels of mastery are people who just do their job and (often without a conscious thought) apply patterns as necessary.

Carpenters don’t think twice about when and how to construct a staircase or put together a 2x6” wall frame. These are common design patterns, but they are natural solutions to common problems.

In short: strive for “pattern mastery” where you are not fixated on the pattern, but instead are just solving problems with natural solutions, such that the pattern “disappears” into the fabric of the overall solution.

The pattern movement has been going on for at least 15 years in our industry. And over that time I think it has been far more beneficial than destructive.

But that doesn’t mean (especially as a consultant) that you don’t walk into many organizations and see horrible misuse of design patterns – the results being higher complexity, lower maintainability and higher cost of development and maintenance.

I think it is important that we continually strive to make patterns be a common abstract language for complex problems and solutions. And I think it is important that we continually educate everyone on development teams about the patterns and implementations we bring into our applications.

But most importantly, I think we need to always make conscious choices, not choices based on trends or fads or because somebody on the team is in love with pattern X or framework Y or technology Z.

  1. Use a pattern because you have the problem it solves
  2. Only use a pattern if the good consequences outweigh the bad (and remember that every pattern has negative consequences)
  3. Use patterns and implementations only if the entire team understands them
  4. Use the simplest pattern that solves your problem
  5. Don’t be afraid to combine several simple patterns to solve a complex problem
  6. Be aware of (and consciously accept) the consequences of any low level patterns that come with most high level pattern implementations
  7. Strive for “pattern mastery”, where you are solving problems with natural solutions, not looking for ways to apply any specific pattern

Eventually maybe we’ll all be in a software development retirement home and we can shout things like “Memento” and “Channel adaptor” and everyone will chuckle with fond memories of how those patterns made our lives easier as we built the software on which the world runs.

Monday, 19 July 2010 11:03:04 (Central Standard Time, UTC-06:00)  #    Disclaimer

Bil Simser tagged me with this meme, thanks Bil.

As I tend to do with these things, I'll answer, but I'm not going to pass it on.

Apparently the idea is to list 5 things that'll make me a better developer over the next 6 months. The problem is, I'm not sure being a better developer is my primary focus just at the moment. But here's my list:

Keep my head above water

Microsoft has recently, and continues into the foreseeable future, to come out with new technology releases at a ridiculous pace. By "head above water" all I really mean is that I want, at least, to have a general clue about the purpose and real capabilities of all the stuff they are throwing at us. Not just the marketing hype, but what it really means. This, to me, has always been one of my primary strengths: the ability to grok most of the technologies available, and to figure out how they fit into some overarching architecture/worldview/philosophy.

But the current rate of change, and the amount of redundancy (ADO.NET, DataSets, LINQ, ADO.NET EF all solving the same problem? Come on!) makes this increasingly challenging. So over the next 6 months I'll be reading, talking to experts (and anyone else with something to offer) and experimenting in the hopes of keeping my head above water.

CSLA .NET

I used to learn new technologies by writing games - specifically MUDs and then low-end MMORPGs (well, I wrote and rewrote parts of one that never really came together). Someday I'd like to get back to doing that.

But in the meantime, I have CSLA .NET, and it has grown enough over the years that it affords me the opportunity to explore most of the key technologies I really want to learn. Having just released version 3.0, I got to dig into the plumbing behind WPF data binding, and explore the details around how WCF supports client/server (which it does well btw). Now my sights are turned toward two targets: .NET 3.5 and Silverlight.

The new language features, and of course lINQ itself, are key areas of focus for CSLA .NET 3.5. Fun stuff, no doubts there!

And if Silverlight 1.1 gets just a few more features (most notably data binding to objects), I believe I can create a CSLA Light that will provide a meaningful subset of CSLA .NET functionality within the Silverlight environment. If that pans out, it will be quite exciting :)

Magenic

Working for Magenic is great! I really enjoy the company and the people I work with. Over the next few months I'll be conciously spending more time and energy working internally with Magenic. As noted above, Microsoft's technology release schedule is grueling, and I want to make sure Magenic's consultants have the opportunity to stay on top of everything. This not only means doing some internal training, but more importantly working to build up a base of expertise and the infrastructure so other people can do some of that training (formally or informally).

It is (in my view) entirely unrealistic for one person to be an expert on everything that's going on. How can you credibly span .NET, Windows, Web, AJAX, SOA, Silverlight, SharePoint, Biztalk, SQL, Windows Server 2008 and everything else? You can't. But Magenic can, because we have a large enough pool of people that there's a decent level of expertise in all these technologies spread across the company. My challenge, then, is to coordinate that expertise such that the experts are in a position to share their knowledge with everyone else who needs it.

Of course Magenic has five offices across the country, and so there's the interesting sub-challenge of enabling the sharing of expertise across geographic distance. Actually it isn't the knowledge sharing that's such a big deal (we have great forums, etc), but it is the sharing if passion that is harder - and yet is at least as important.

Don't burn out

I've been feeling seriously burned out of late. That's not good. Part of it is due to the way travel grates on me more all the time, but most of it is that I haven't spent time doing truly exploratory things for a very long time now. CSLA has become quite consuming, and so my spare time goes into the framework, when I could be working on a .NET MUD engine or something really fun like that (I have these cool prototypes for truly dynamic world behavior that I'd love to pull together into something real).

It is also the case that I'm terrible about taking vacations. If I vacation at home, I work. That's the primary drawback with having a home office - work is always right there. But with Smartphones and laptops with wireless and/or cell modems the "office" can go almost anywhere, so even with a traditional office, escape is almost impossible.

Except... In August I'm spending a full week (nearly 10 days) in or near the Boundary Waters in far northern Minnesota. No meaningful cell coverage, no Starbucks or anywhere like it that would have wireless. Just untold miles and miles of wilderness, canoing, camping and fishing. Yea!

Remember the passion

Have you ever played that "what if" game? The one where you ask youself what job you'd do if you didn't do your current job?

I always draw a blank. If I had to do something else it would actually be work, rather than what I do now, which is to get paid for my hobby.

This, by the way, is what bothers me most about outsourcing, or even the software factory concept. It is true that economic needs shift over time, and steel workers needed to get new skills to find new jobs (as an example). I suppose it is possible that many of those steel workers had a burning passion for their job. That working with steel was their hobby as well as their job. But I doubt it. Most people I know view work as work: as a way to make money so they can do what they really want to do in their off hours. On the other hand, most developers I know view work as fun - and a way to make money while having fun.

Economists are often dismissive toward us, saying that if our jobs go offshore that we can just learn new skills and find different jobs. What they fail to understand is that we'd be doing far more than switching jobs: we'd be giving up an entire way of life. We'd be moving from a world of creative inspiration to a world of soul-crushing tedium. Yes, I realize I'm probably being very condenscending toward people with "normal" jobs, but this is how I see the world... (Then again, maybe economists do realize the deep love we have for what we do, and they envy us and so feel no remorse in talking about the destruction of our way of life?)

In any case, I love aspects of technology (especially building distributed and/or quasi-autonomous systems). And I love teaching about development. These things have been my passion since long before I officially started my career (when I was just a teenager, I was teaching elementary school kids how to use those new-fangled computers (Apples with no floating point support)). And I love writing - I really am what JMS describes as an "author" (one cursed to write because they can't not write). I can't imagine not doing most of the things I do today.

I think that's the key: remember the passion. Remember the fun. Yes, work hard, but more importantly code well, and perhaps above all: have fun!

Thursday, 12 July 2007 10:38:00 (Central Standard Time, UTC-06:00)  #    Disclaimer

There's this "five things about me" tagging meme going around, and I've now been tagged by Bill, Craig and Andrea.

1. I grew up in the middle of Minnesota, surrounded by hundreds of acres of forest and lakes. Our nearest neighbor was a mile away. The nearest town 14 miles away, and the nearest real town over 30 miles away. The nearest city: a 2.5 hour drive. As a youth, I lived one of those lives of adventure you might read about from long in the past. I spent my time fishing, hunting, trapping, snowmobiling, boating, swimming and generally wandering through the woods and lakes of central Minnesota.

2. I love alternative metal and alternative rock. Rush, Queensryche, Godsmack, Linkin Park and so forth. Good rock, to me, requires thought-provoking lyrics, evocative sound and serious riffs!

3. I love speculative fiction (the fancy name for science fiction and fantasy). Tolkien, Asimov, Niven, Reynolds, Scalzi, McKillip, Norton and many others are on my favorites list. Between all these books, and my wife's collection of all the essays, letters and other writings of America's founding fathers (plus many random other books on many topics) we have an entire room set aside as a library.

4. My first overseas trip was to London, to attend a Babylon 5 convention to commemorate the conclusion of the show. My wife was (and technically still is) a moderator on the Babylon 5 moderated newsgroup (remember usenet? :) ).

5. I'm a would-be game developer. Years ago I wrote a MUD for the DEC VAX called Mordecai. It consumed all the resources the university VAX could muster back then, and I even ended up working with the Operations guys to build in capabilities to throttle the game so it wouldn't be playable during prime homework usage periods and that sort of thing. I've written bits and pieces of a much more ambitious .NET equivalent, but that project stalled a while back. The reality today is that game development is such a small part of building a game in total (graphics, physics engines and so forth are a much bigger part) that it is hard to get as excited about this stuff as I used to be...

Kindly enough, and because I don't have time to track down who's been tagged or not, I'm not tagging anyone, so this thread of execution ends here ;)

Wednesday, 24 January 2007 19:44:48 (Central Standard Time, UTC-06:00)  #    Disclaimer

There’s a thread on the CSLA .NET discussion forum about possible differences between the VB and C# versions of CSLA .NET. I started to answer the thread, then got on a roll, so it became a blog entry :-)

 

I strive to keep the two versions of CSLA .NET in sync within a reasonable time window. Everything after version 1.0 (the version in my books) is essentially my donation to the community. What I get out of it is not wealth, but rather is a lot of very interesting and useful feedback from the vibrant CSLA .NET community. I'm able to try out some of the most interesting (to me) ideas by releasing new and updated versions of the code. It is a learning opportunity.

 

The fact that I have to do every mod twice is a serious pain and does reduce the fun, but I think it is worth the pain because it makes the end result more useful for everyone.

 

I do most of my first-run coding in VB, because I prefer it. Simple personal preference. I've done some first-run coding in C# too, I just don't find it as enjoyable. Some people have the reverse experience and that's cool too. That doesn't bother me one way or the other. I fully understand feeling an affinity toward a specific language. It took me years to get over Pascal. Ahh VAX Pascal, I still harbor such fond memories.

 

But what I am more concerned about in terms of CSLA .NET is VS 2005. In .NET 2.0 we start to see some feature divergence between VB and C#. Most notably the My namespace in VB. Fortunately by playing in the middle-tier, CSLA is less subject to the differences than some code will be. However, there'll still be some differences that will make my dual life harder.

 

The biggest one that will impact me is My.Resources, which makes the use of resources somewhat simpler than C#. This isn't a huge thing, but it does mean there'll be extra code differences to reconcile between the two versions in CSLA .NET 2.0.

 

There's also My.Settings, though I don't know if that will impact me quite as much. I anticipate dropping the DB() function from BusinessBase in 2.0, since most people (rightly) avoid putting db connection strings in their config files.

 

The two primary C# features (yield and anonymous delegates) don't appear to have a home in CSLA, so I don't expect any differences from them. Not that they aren’t seriously cool features, but they just don’t have a place in CSLA .NET itself.

 

The new strongly typed TableAdapter classes are very cool. They are useful in both languages. And I hope to use strongly typed TableAdapter objects to simplify the code in the DataPortal_xyz methods.

 

There are some features that are more accessible to VB than C# in the new strongly typed DataTable (due to C#'s lack of WithEvents functionality - a major oversight imo). However, I don't expect to use any of those features in CSLA to start with, so there's no impact there.

 

When I write the book I'll create Windows and Web UI chapters. Those are what I dread most, because that's where the differences due to My become much more serious. There are numerous examples of UI development where My will be a serious code-saver - thus causing direct differences between the VB and C# code. Not that I can't do the same stuff in C#, just that it will take more and different code, which increases the effort on my part as an author.

 

Fortunately most of the book is about the framework and creating business objects, and the language divergence will have relatively minimal impact in those areas.

 

It is hard to speculate on what comes after VS 2005, but personally I expect more divergence, not less. Earlier in the thread someone noted that things like the Mac, Linux and Java still exist even though you can technically do everything they do with Windows and .NET.

 

The fact is that they all serve a purpose, as does .NET to them. People deep in C# often think different than those deep in VB. People in Java think different than those in .NET. This means they have different perspectives, different priorities, on the same problems and issues. This is only good. This means there are competing ideas that we can all evaluate and use to the best of our abilities, regardless of the language or platform we choose to use.

 

Loving distributed computing as I do, I am constantly taking ideas from the C++ and Java worlds. I closely watch the SOA world, even though I think it is misguided in many ways, because there are interesting ideas and perspectives there that can apply to distributed object-oriented systems as well.

 

I’ve said it before and I’ll say it again, if you only know one programming language family (such as the C family or the Basic family) then you really, really need to get out more. Your horizons and thus your career are simply too limited and you can’t be considered credible in most of these discussions.

 

That’s an interesting meme. Which programming languages have you been competent in during your career? I’ll start (in rough order of usage):

 

1.      Apple BASIC

2.      VAX Pascal

3.      Turbo Pascal

4.      DCL

5.      FORTRAN 90

6.      VAX Basic

7.      ARexx

8.      Modula-II

9.      Visual Basic (1-6)

10.  Visual Basic .NET

11.  C#

 

While I did write a VT terminal emulator in C once, I don’t think I was ever really competent in C, so I’m not counting that. My memories of that experience are not inspirational in the slightest… I’ve also dabbled in various Unix shell languages and bat files, but was never competent in them.

 

Converting the list to language families is harder, because things like ARexx aren’t obvious, but here’s my attempt:

 

1.      Pascal (Pascals and Modula-II)

2.      Basic (various)

3.      FORTRAN

4.      Scripting (ARexx, DCL)

5.      C (C# and C if you are generous)

 

So, having wandered from the topic of CSLA .NET parity between VB and C# we arrive at what could be a cool meme. Go ahead, comment or blog – what languages and language families have you been competent in during your career?

Monday, 14 February 2005 18:50:22 (Central Standard Time, UTC-06:00)  #    Disclaimer

I was just at a family reunion and heard a joke about the comedian’s retirement home. A guy walks into the common room and hears one old guy shout out “19”, and everyone laughs. Across the room another guy shouts out “54” and everyone laughs even harder. The guy turns to his guide and asks “What is going on?”. The guide replies “These guys know all the same jokes, and at their age it takes too long to tell them, so they just assigned them all numbers.” The guy smiles, and shouts out “92”, which results in a just a few grudging chuckles. “What’d I do wrong?” he asks the guide. The guide replies “Some people can tell a joke, some people can’t.”

That made me think about patterns (yes, I know, I’m a geek).

I like design patterns. Who wouldn’t? They are a formalized description of a solution to a specific problem. If you have that problem, then having a formally described solution seems like a dream come true.

Perhaps more importantly patterns are a language short-cut. If everyone in a conversation understands a pattern, the pattern (and often its problem) can be discussed merely by using the pattern name, which saves an immense amount of time as opposed to describing the actual problem and solution in detail.

Of course the “formalized description” is prose. Human language. And therefore it is ambiguous and open to interpretation. The descriptions must be human-readable, because any pattern worth ink and paper transcends any specific platform or programming language. Describing a “pattern” in Java or C# is silly – because that makes it far too likely that it isn’t really a broad pattern, but is simply a practice that happens to work in a given language or on a given platform.

But this ambiguity leads to trouble. Not unlike the comedian’s retirement home, patterns are a short-cut language to some really complex concepts, and often even more complex implementations. While everyone might have a basic comprehension of “inversion of control”, I can guarantee you that saying IoC doesn’t bring the same concept, implementation or emotional response from everyone who hears it.

Pattern zealots often forget (or overlook) the fact that patterns have consequences. Good and bad consequences. Every pattern has bad consequences, as well as good ones. Some people get attached to a pattern because it helped them at some point, and they just assume that pattern will always have a positive or beneficial result. But that’s simply not true. Sometimes the negative consequences of a pattern outweigh the positive – it is all very dependent on the specific problem domain and environment.

Soft things like staffing levels, skill sets, attitudes and time frames all enter into the real world environment. Add the reality that any given problem almost certainly has several patterns that provide solutions – for different variations of the problem – and it becomes clear that no one pattern is always “good”.

It should come as no surprise then, that patterns are often misused – in several different ways.

My pet peeve is when a pattern is applied because something likes the pattern, not because the application actually has the problem the pattern would solve. I often see people using IoC, for example, because it is trendy, not because they actually need the flexibility provided by the pattern. They use a container to create instances of objects that they will never swap out for other implementations. What a waste – they’ve accepted all the negative consequences of the pattern for absolutely no benefit since they don’t have the problem the pattern would solve. Is this the fault of IoC? Of course not, IoC is a powerful pattern.

It is the fault of what I call the “Pattern Of The Year” (POTY) syndrome. When a pattern becomes really popular and trendy, it becomes the POTY. And everyone wants to go to the POTY. If you need the POTY, you should go. But if you don’t need the POTY, it is really a little silly (if not creepy) for you to go to the POTY…

In short: only use a pattern if you have the problem it solves, and the positive consequences outweigh the negative consequences.

Perhaps the most common misuse of patterns is failure to actually understand the pattern or its implementation. To stick with IoC as an example, it is pretty common for a development team to completely misunderstand the pattern or the framework that implements the pattern. Sure, some architect or lead developer “got it” (or so we hope) which is why the team is using the pattern – but you can find apps where numerous competing containers are created, each initialized differently.

I always thought Apple BASIC spaghetti code was the worst thing possible – but misuse of certain design patterns quickly creates a mess that is an order of magnitude worse than anything people wrote back in the early 80’s…

In short: if you use a pattern, make sure your entire team understand the pattern and your implementation of the pattern.

As I mentioned earlier, most problems can be solved by more than one pattern. Any truly interesting problem almost certainly has multiple solutions, each with different good/bad consequences and various subtle differences in outcome. It is not uncommon for the best solution to be a combination of a few more basic patterns.

As an example, the CSLA data portal is a combination of around six basic design patterns that work together in concert to solve the problem space the data portal targets. I’m not saying the data portal is a design pattern, but it is a solution for a problem that came into being by combining several complimentary patterns.

A few years after I created the data portal, various other design patterns were formalized that describe other solutions to this same problem space. Some are similar, some are not. If you look into each solution, it is clear that each one is actually a different combination of some lower level design patterns, working together to solve the problem.

The thing is, every pattern your bring into your solution (or ever pattern brought in by a higher level pattern) comes with its own consequences. You need to be careful to minimize the negative consequences of all those patterns so the overall balance is toward the positive.

In short: don’t be afraid to combine simple or basic design patterns together to solve a bigger problem, but be aware of the negative consequences of every pattern you bring into play.

Having introduced this concept of “low level” vs “high level” patterns, I’m going to follow that a bit further. Most of the patterns in the original GoF book are what I’d call low level patterns. They stand alone and have little or no dependency on each other. Each one solves a very narrow and clear problem and has very clear good/bad consequences.

Of course that was 15 years ago, and since then people have applied the pattern concept to more complex and bigger problem spaces. The resulting solutions (patterns) very often build on other patterns. In other words we’re raising the level of abstraction by building on previous abstractions. And that’s a fine thing.

But it is really important to understand that ultimately patterns are implemented, and the implementations of patterns are often far messier than the abstract though models provided by the patterns themselves. Even that is OK, but there’s a meta-consequence the flows out of this: complexity.

As you start to use higher level patterns, and their implementations, you can easily become locked into not only the implementation of the pattern you wanted, but also the implementations of the lower level patterns on which the implementation is built.

Again I’ll use IoC to illustrate my point. If you want IoC you’ll almost certainly use a pre-existing implementation. And once you pick that framework, you are stuck with it. You won’t want to use more than one IoC framework, because then you’d have multiple containers, each configured differently and each competing for the attention of every developer. The result is a massive increase in complexity, which means a reduction in maintainability and a corresponding increase in cost.

Now suppose you pick some higher level pattern, perhaps a portal or gateway, that is implemented using IoC. If you want the implementation of the gateway pattern you must also accept a dependency on their IoC framework choice.

People often ask me whether (or when will) CSLA .NET will incorporate Enterprise Library, log4net, Unity, Castle/Windsor, <insert your framework here>. I try very, very, very hard to avoid any such dependencies, because as soon as I pick any one of these, I make life really hard for everyone out there who didn’t choose that other framework.

CSLA 3.8 has a dependency on a simple data structure framework, and even that was a continual nightmare. I can hardly express how happy I am that I was able to get rid of that dependency for CSLA 4. Not that the data structure framework was bad – it does a great job – but the complexity introduced by the dependency was just nasty.

In short: be aware of the complexity introduced as high level patterns force you to accept dependencies on lower level patterns and implementations.

The final topic I’d like to cover flows from a conversation I had with Ward Cunningham a few years ago. We were talking about patterns and the “pattern movement”, and how it has become a little warped over time as people actively look for ways to apply patterns, rather than the patterns being used because they are the natural answer to a problem.

It is kind of like a carpenter who spends a lot of money buying some really nice new power tool. And then trying to use that power tool for every part of the construction process – even if that means being less efficient or increasing the complexity of the job – just to use the tool.

Obviously I’d never want to hire such a carpenter to work on my house!!

Yet I’ve seen developers and architects get so fascinated by specific patterns, frameworks or technologies that they do exactly that: increase the complexity of simple problem domains specifically so they can use their new toy concept.

In this conversation Ward suggested that there are different levels of understanding or mastery of patterns. At the most basic level are people just learning what patterns are, followed by people who “get” a pattern and actively seek opportunities to use that pattern. But at higher levels of mastery are people who just do their job and (often without a conscious thought) apply patterns as necessary.

Carpenters don’t think twice about when and how to construct a staircase or put together a 2x6” wall frame. These are common design patterns, but they are natural solutions to common problems.

In short: strive for “pattern mastery” where you are not fixated on the pattern, but instead are just solving problems with natural solutions, such that the pattern “disappears” into the fabric of the overall solution.

The pattern movement has been going on for at least 15 years in our industry. And over that time I think it has been far more beneficial than destructive.

But that doesn’t mean (especially as a consultant) that you don’t walk into many organizations and see horrible misuse of design patterns – the results being higher complexity, lower maintainability and higher cost of development and maintenance.

I think it is important that we continually strive to make patterns be a common abstract language for complex problems and solutions. And I think it is important that we continually educate everyone on development teams about the patterns and implementations we bring into our applications.

But most importantly, I think we need to always make conscious choices, not choices based on trends or fads or because somebody on the team is in love with pattern X or framework Y or technology Z.

  1. Use a pattern because you have the problem it solves
  2. Only use a pattern if the good consequences outweigh the bad (and remember that every pattern has negative consequences)
  3. Use patterns and implementations only if the entire team understands them
  4. Use the simplest pattern that solves your problem
  5. Don’t be afraid to combine several simple patterns to solve a complex problem
  6. Be aware of (and consciously accept) the consequences of any low level patterns that come with most high level pattern implementations
  7. Strive for “pattern mastery”, where you are solving problems with natural solutions, not looking for ways to apply any specific pattern

Eventually maybe we’ll all be in a software development retirement home and we can shout things like “Memento” and “Channel adaptor” and everyone will chuckle with fond memories of how those patterns made our lives easier as we built the software on which the world runs.

Monday, 19 July 2010 11:03:04 (Central Standard Time, UTC-06:00)  #    Disclaimer

Bil Simser tagged me with this meme, thanks Bil.

As I tend to do with these things, I'll answer, but I'm not going to pass it on.

Apparently the idea is to list 5 things that'll make me a better developer over the next 6 months. The problem is, I'm not sure being a better developer is my primary focus just at the moment. But here's my list:

Keep my head above water

Microsoft has recently, and continues into the foreseeable future, to come out with new technology releases at a ridiculous pace. By "head above water" all I really mean is that I want, at least, to have a general clue about the purpose and real capabilities of all the stuff they are throwing at us. Not just the marketing hype, but what it really means. This, to me, has always been one of my primary strengths: the ability to grok most of the technologies available, and to figure out how they fit into some overarching architecture/worldview/philosophy.

But the current rate of change, and the amount of redundancy (ADO.NET, DataSets, LINQ, ADO.NET EF all solving the same problem? Come on!) makes this increasingly challenging. So over the next 6 months I'll be reading, talking to experts (and anyone else with something to offer) and experimenting in the hopes of keeping my head above water.

CSLA .NET

I used to learn new technologies by writing games - specifically MUDs and then low-end MMORPGs (well, I wrote and rewrote parts of one that never really came together). Someday I'd like to get back to doing that.

But in the meantime, I have CSLA .NET, and it has grown enough over the years that it affords me the opportunity to explore most of the key technologies I really want to learn. Having just released version 3.0, I got to dig into the plumbing behind WPF data binding, and explore the details around how WCF supports client/server (which it does well btw). Now my sights are turned toward two targets: .NET 3.5 and Silverlight.

The new language features, and of course lINQ itself, are key areas of focus for CSLA .NET 3.5. Fun stuff, no doubts there!

And if Silverlight 1.1 gets just a few more features (most notably data binding to objects), I believe I can create a CSLA Light that will provide a meaningful subset of CSLA .NET functionality within the Silverlight environment. If that pans out, it will be quite exciting :)

Magenic

Working for Magenic is great! I really enjoy the company and the people I work with. Over the next few months I'll be conciously spending more time and energy working internally with Magenic. As noted above, Microsoft's technology release schedule is grueling, and I want to make sure Magenic's consultants have the opportunity to stay on top of everything. This not only means doing some internal training, but more importantly working to build up a base of expertise and the infrastructure so other people can do some of that training (formally or informally).

It is (in my view) entirely unrealistic for one person to be an expert on everything that's going on. How can you credibly span .NET, Windows, Web, AJAX, SOA, Silverlight, SharePoint, Biztalk, SQL, Windows Server 2008 and everything else? You can't. But Magenic can, because we have a large enough pool of people that there's a decent level of expertise in all these technologies spread across the company. My challenge, then, is to coordinate that expertise such that the experts are in a position to share their knowledge with everyone else who needs it.

Of course Magenic has five offices across the country, and so there's the interesting sub-challenge of enabling the sharing of expertise across geographic distance. Actually it isn't the knowledge sharing that's such a big deal (we have great forums, etc), but it is the sharing if passion that is harder - and yet is at least as important.

Don't burn out

I've been feeling seriously burned out of late. That's not good. Part of it is due to the way travel grates on me more all the time, but most of it is that I haven't spent time doing truly exploratory things for a very long time now. CSLA has become quite consuming, and so my spare time goes into the framework, when I could be working on a .NET MUD engine or something really fun like that (I have these cool prototypes for truly dynamic world behavior that I'd love to pull together into something real).

It is also the case that I'm terrible about taking vacations. If I vacation at home, I work. That's the primary drawback with having a home office - work is always right there. But with Smartphones and laptops with wireless and/or cell modems the "office" can go almost anywhere, so even with a traditional office, escape is almost impossible.

Except... In August I'm spending a full week (nearly 10 days) in or near the Boundary Waters in far northern Minnesota. No meaningful cell coverage, no Starbucks or anywhere like it that would have wireless. Just untold miles and miles of wilderness, canoing, camping and fishing. Yea!

Remember the passion

Have you ever played that "what if" game? The one where you ask youself what job you'd do if you didn't do your current job?

I always draw a blank. If I had to do something else it would actually be work, rather than what I do now, which is to get paid for my hobby.

This, by the way, is what bothers me most about outsourcing, or even the software factory concept. It is true that economic needs shift over time, and steel workers needed to get new skills to find new jobs (as an example). I suppose it is possible that many of those steel workers had a burning passion for their job. That working with steel was their hobby as well as their job. But I doubt it. Most people I know view work as work: as a way to make money so they can do what they really want to do in their off hours. On the other hand, most developers I know view work as fun - and a way to make money while having fun.

Economists are often dismissive toward us, saying that if our jobs go offshore that we can just learn new skills and find different jobs. What they fail to understand is that we'd be doing far more than switching jobs: we'd be giving up an entire way of life. We'd be moving from a world of creative inspiration to a world of soul-crushing tedium. Yes, I realize I'm probably being very condenscending toward people with "normal" jobs, but this is how I see the world... (Then again, maybe economists do realize the deep love we have for what we do, and they envy us and so feel no remorse in talking about the destruction of our way of life?)

In any case, I love aspects of technology (especially building distributed and/or quasi-autonomous systems). And I love teaching about development. These things have been my passion since long before I officially started my career (when I was just a teenager, I was teaching elementary school kids how to use those new-fangled computers (Apples with no floating point support)). And I love writing - I really am what JMS describes as an "author" (one cursed to write because they can't not write). I can't imagine not doing most of the things I do today.

I think that's the key: remember the passion. Remember the fun. Yes, work hard, but more importantly code well, and perhaps above all: have fun!

Thursday, 12 July 2007 10:38:00 (Central Standard Time, UTC-06:00)  #    Disclaimer

There's this "five things about me" tagging meme going around, and I've now been tagged by Bill, Craig and Andrea.

1. I grew up in the middle of Minnesota, surrounded by hundreds of acres of forest and lakes. Our nearest neighbor was a mile away. The nearest town 14 miles away, and the nearest real town over 30 miles away. The nearest city: a 2.5 hour drive. As a youth, I lived one of those lives of adventure you might read about from long in the past. I spent my time fishing, hunting, trapping, snowmobiling, boating, swimming and generally wandering through the woods and lakes of central Minnesota.

2. I love alternative metal and alternative rock. Rush, Queensryche, Godsmack, Linkin Park and so forth. Good rock, to me, requires thought-provoking lyrics, evocative sound and serious riffs!

3. I love speculative fiction (the fancy name for science fiction and fantasy). Tolkien, Asimov, Niven, Reynolds, Scalzi, McKillip, Norton and many others are on my favorites list. Between all these books, and my wife's collection of all the essays, letters and other writings of America's founding fathers (plus many random other books on many topics) we have an entire room set aside as a library.

4. My first overseas trip was to London, to attend a Babylon 5 convention to commemorate the conclusion of the show. My wife was (and technically still is) a moderator on the Babylon 5 moderated newsgroup (remember usenet? :) ).

5. I'm a would-be game developer. Years ago I wrote a MUD for the DEC VAX called Mordecai. It consumed all the resources the university VAX could muster back then, and I even ended up working with the Operations guys to build in capabilities to throttle the game so it wouldn't be playable during prime homework usage periods and that sort of thing. I've written bits and pieces of a much more ambitious .NET equivalent, but that project stalled a while back. The reality today is that game development is such a small part of building a game in total (graphics, physics engines and so forth are a much bigger part) that it is hard to get as excited about this stuff as I used to be...

Kindly enough, and because I don't have time to track down who's been tagged or not, I'm not tagging anyone, so this thread of execution ends here ;)

Wednesday, 24 January 2007 19:44:48 (Central Standard Time, UTC-06:00)  #    Disclaimer

There’s a thread on the CSLA .NET discussion forum about possible differences between the VB and C# versions of CSLA .NET. I started to answer the thread, then got on a roll, so it became a blog entry :-)

 

I strive to keep the two versions of CSLA .NET in sync within a reasonable time window. Everything after version 1.0 (the version in my books) is essentially my donation to the community. What I get out of it is not wealth, but rather is a lot of very interesting and useful feedback from the vibrant CSLA .NET community. I'm able to try out some of the most interesting (to me) ideas by releasing new and updated versions of the code. It is a learning opportunity.

 

The fact that I have to do every mod twice is a serious pain and does reduce the fun, but I think it is worth the pain because it makes the end result more useful for everyone.

 

I do most of my first-run coding in VB, because I prefer it. Simple personal preference. I've done some first-run coding in C# too, I just don't find it as enjoyable. Some people have the reverse experience and that's cool too. That doesn't bother me one way or the other. I fully understand feeling an affinity toward a specific language. It took me years to get over Pascal. Ahh VAX Pascal, I still harbor such fond memories.

 

But what I am more concerned about in terms of CSLA .NET is VS 2005. In .NET 2.0 we start to see some feature divergence between VB and C#. Most notably the My namespace in VB. Fortunately by playing in the middle-tier, CSLA is less subject to the differences than some code will be. However, there'll still be some differences that will make my dual life harder.

 

The biggest one that will impact me is My.Resources, which makes the use of resources somewhat simpler than C#. This isn't a huge thing, but it does mean there'll be extra code differences to reconcile between the two versions in CSLA .NET 2.0.

 

There's also My.Settings, though I don't know if that will impact me quite as much. I anticipate dropping the DB() function from BusinessBase in 2.0, since most people (rightly) avoid putting db connection strings in their config files.

 

The two primary C# features (yield and anonymous delegates) don't appear to have a home in CSLA, so I don't expect any differences from them. Not that they aren’t seriously cool features, but they just don’t have a place in CSLA .NET itself.

 

The new strongly typed TableAdapter classes are very cool. They are useful in both languages. And I hope to use strongly typed TableAdapter objects to simplify the code in the DataPortal_xyz methods.

 

There are some features that are more accessible to VB than C# in the new strongly typed DataTable (due to C#'s lack of WithEvents functionality - a major oversight imo). However, I don't expect to use any of those features in CSLA to start with, so there's no impact there.

 

When I write the book I'll create Windows and Web UI chapters. Those are what I dread most, because that's where the differences due to My become much more serious. There are numerous examples of UI development where My will be a serious code-saver - thus causing direct differences between the VB and C# code. Not that I can't do the same stuff in C#, just that it will take more and different code, which increases the effort on my part as an author.

 

Fortunately most of the book is about the framework and creating business objects, and the language divergence will have relatively minimal impact in those areas.

 

It is hard to speculate on what comes after VS 2005, but personally I expect more divergence, not less. Earlier in the thread someone noted that things like the Mac, Linux and Java still exist even though you can technically do everything they do with Windows and .NET.

 

The fact is that they all serve a purpose, as does .NET to them. People deep in C# often think different than those deep in VB. People in Java think different than those in .NET. This means they have different perspectives, different priorities, on the same problems and issues. This is only good. This means there are competing ideas that we can all evaluate and use to the best of our abilities, regardless of the language or platform we choose to use.

 

Loving distributed computing as I do, I am constantly taking ideas from the C++ and Java worlds. I closely watch the SOA world, even though I think it is misguided in many ways, because there are interesting ideas and perspectives there that can apply to distributed object-oriented systems as well.

 

I’ve said it before and I’ll say it again, if you only know one programming language family (such as the C family or the Basic family) then you really, really need to get out more. Your horizons and thus your career are simply too limited and you can’t be considered credible in most of these discussions.

 

That’s an interesting meme. Which programming languages have you been competent in during your career? I’ll start (in rough order of usage):

 

1.      Apple BASIC

2.      VAX Pascal

3.      Turbo Pascal

4.      DCL

5.      FORTRAN 90

6.      VAX Basic

7.      ARexx

8.      Modula-II

9.      Visual Basic (1-6)

10.  Visual Basic .NET

11.  C#

 

While I did write a VT terminal emulator in C once, I don’t think I was ever really competent in C, so I’m not counting that. My memories of that experience are not inspirational in the slightest… I’ve also dabbled in various Unix shell languages and bat files, but was never competent in them.

 

Converting the list to language families is harder, because things like ARexx aren’t obvious, but here’s my attempt:

 

1.      Pascal (Pascals and Modula-II)

2.      Basic (various)

3.      FORTRAN

4.      Scripting (ARexx, DCL)

5.      C (C# and C if you are generous)

 

So, having wandered from the topic of CSLA .NET parity between VB and C# we arrive at what could be a cool meme. Go ahead, comment or blog – what languages and language families have you been competent in during your career?

Monday, 14 February 2005 18:50:22 (Central Standard Time, UTC-06:00)  #    Disclaimer
On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
June, 2017 (1)
May, 2017 (1)
April, 2017 (2)
March, 2017 (1)
February, 2017 (2)
January, 2017 (2)
December, 2016 (5)
November, 2016 (2)
August, 2016 (4)
July, 2016 (2)
June, 2016 (4)
May, 2016 (3)
April, 2016 (4)
March, 2016 (1)
February, 2016 (7)
January, 2016 (4)
December, 2015 (4)
November, 2015 (2)
October, 2015 (2)
September, 2015 (3)
August, 2015 (3)
July, 2015 (2)
June, 2015 (2)
May, 2015 (1)
February, 2015 (1)
January, 2015 (1)
October, 2014 (1)
August, 2014 (2)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2017, Marimer LLC

Send mail to the author(s) E-mail



Sign In