December 2009 - Posts

It’s time to look ahead to 2010

Before I discuss my 2010 predictions, it’s important to provide a disclaimer using my 2009 predictions.  One of my predictions was spot on.  At the end of this post, I said:

“Of course, I’m probably wrong about many of these.”

That one was right. The other four, less so. Cloud Computing has not achieved the market share I would have thought it would by now. I’m going to call that one “delayed” not “wrong”. I still think Cloud Computing will be important, it is just taking longer. Rich Internet Applications was just plain wrong. While I think (almost) every application will make use of the internet, and people want rich applications, the term will lose favor. It won’t have meaning if everything is ‘rich’ and ‘internet’. “Multi-touch goes mainstream”. Not yet. I still think that will happen. The mouse as a metaphor is very long in the tooth. We do crave better ways to interact with our computers. We have it with some special purpose applications. We’ll get there with other apps as well. My final prediction “Social Networking as a business tool”, was much better. In the last year, Detroit and Ann Arbor newspapers stopped printing. I didn’t miss a beat. All those papers have great web sites (http://www.freep.com, http://www.detnews.com, and http://www.annarbor.com). Even more immediate, all those sources, and several of their reporters are on twitter. I get news more quickly following them, and following their links than I did reading the dead tree edition with my morning coffee.

On to 2010 Predictions

Armed with the confidence that I’m probably wrong, I’m ready to divulge my thoughts about 2010.

Polyglot Programming Languages

For the past few years, many industry leaders were saying that developers needed to know multiple languages. They were right, because learning multiple languages (if done correctly) meant that you needed to learn different programming idioms: procedural programming, object oriented programming, functional programming, and so on.

But that’s painful. Why should I need to learn new syntax to use new idioms? Curly braces aren’t allowed in FP? semicolons aren’t permitted in dynamic languages?

Instead, why can’t a general purpose programming language support multiple programming idioms? C#, VB.NET, and C++ are starting to seriously support that. (Other languages may be doing this as well; I don’t know). All these languages have added (or are adding) lambda expressions which support functional programming concepts. (C++ has used Class Type Functors for this purpose for some time). C# is adding support for dynamic typing (as is VB.NET, in a more strict fashion than previously supported). Implicit typing is supported in C#, C++, and VB.NET as well.

This trend will continue as more and more developers want to use the best programming idiom for a particular task without learning a totally different syntax. Any programming language that calls itself a “general purpose language” will support multiple idioms.

Value Placed on Comp. Sci Skills

For the past several years, the conventional wisdom has been that ‘business skills’ are more important than ‘core technical skills’. That trend is changing. While I don’t believe we’ll return to those days where anti-social behavior is tolerated (or worse, celebrated), I do believe that serious technical talent is valued more than it was. Even The Economist has predicted fewer MBA students in the coming year, saying it will “…cut off the supply of bullshit at the source.” 

OK, MBAs aren’t that bad. Or, maybe they are. But the fact is that technical talent and skill is important. “Soft Skills” complement hard skills; they aren’t a substitute.

In 2010, more companies will want Comp Sci or Software Engineering grads for their developer positions.

Small, Focused Applications Rule

In an interconnected world, large enterprises are no longer going to tolerate the “One Application to Rule them All” concept. They will start looking for best of breed solutions to each individual problem. The suites that solve everything are going to decrease in value. (or at least customer value). They do everything, but not exactly the way a large enterprise wants. More importantly, they don’t have the integration points needed between these important processes.

Finally, CIOs will be looking to avoid “vendor lock in”, whether that’s a real strategy, or just defensive posturing.

But APIs are the Key Value

Balancing that trend is the fact that too many business processes are stitched together from disparate programs that have no interoperability strategy. Businesses cannot compete if their disparate programs don’t coordinate automatically. It’s too much friction, and no added value. In fact, that’s what drove the trend toward the enterprise suites that claimed to do everything: it was a way to finesse the interoperability requests.

Going forward, the single most important feature for business programs will be data import / export. That must be in a standard format, and it must be a programmable API.IT may or may not be REST, SOAP, or some new made up word. But, I’m confident that any serious product in the business world will have a clear strategy to interoperate with other programs that solve other business problems.

Conclusions

These last two predictions will mean that future systems will built using these concepts:

1. Each process is a small, focused applications that solves a single problem.
2. The inputs and outputs of that process will be in a standard format.
3. Enterprise developers will stitch together different commercial applications are handle *part* of their business processes.

Notice how those last two also fit well with the cloud strategy? Processes in the cloud. You’ll interact with those small processes using a rich UI on whatever screen you have.

Of course, I’m probably wrong again.

Posted 31 December 2009 07:23 PM by wwagner | 4 comment(s)

Filed under: Me, upcoming attractions, SrtInsights

Changed and rewritten items: Effective C# 2nd edition

In my last post, I wrote about the new items in the second edition of Effective C#, and those items that were removed to make room for the new items. Now, let’s discuss what happened to the items that I carried over from the previous edition.

Every item received a rather significant update for this new versions. However, you won’t see that from looking at the table of contents in InformIT. That’s because the advice is very similar to the earlier edition. However, the way you implement the advice has changed significantly. As I mentioned in the last post, the C# language has made many significant enhancements over the years since the first edition was published. We have many different tools at our disposal to express our designs. That means we have many new techniques that we can use to achieve the same goals of better software, and clearly communicating our designs to other developers.

In the new edition, I re-wrote all the samples to use the latest version of C#, taking advantage of all the features in C# 4.0. That does not mean I use C# 4.0 syntax in every single item. It does mean that I thought about how to express an idea using the full palette of features available in C# 4. In many cases, that meant using features available in C# 3, or even C# 2. In other cases, the samples will include some of the latest C# features. In all cases, I updated the justifications for the advice, and how to implement the goals, in the context of C# 4.0.

Even if you have no experience with earlier versions of C#, you can use the advice in the second edition. Furthermore, you can use much of the advice even if you have not updated your environment to C# 4.0, and .NET 4.0.

Posted 17 December 2009 02:58 PM by wwagner | no comments

Filed under: Effective C#, upcoming attractions, C# General

Effective C#, 2nd Edition: What Content got dropped, and why?

The 2nd edition of Effective C# is now available on Rough Cuts. With that, I’ve started to get questions via email about how I decided which items to add, and which items to drop.

It should be clear from the additional content what’s new: I added coverage of the significant C#4.0 features like dynamic invocation and named / optional parameters. New library additions like PLINQ are also covered.

It’s much harder to see how I decided which items to drop. There are 15 completely new items in the 2nd edition, so that meant finding 15 items to drop. (Several other items have the same title, but were significantly rewritten – that will be the subject of another blog post.) Here’s how I decided which items to remove:

Items that are less important now. A number of the items in the first edition discussed techniques that were much more important before generics were available. Some of these items were those that discussed boxing and unboxing, the collection classes, and the data set class. All of those techniques and libraries were far more useful in C# 1.x than in the current .NET universe.

Items that have become common practice. C# has been around for almost a decade, and the community is much more mature than it was in 2004, when Effective C# was published. Some of the items are part of the conventional wisdom now

Items that assumed your last language was C++ or Java. The early adopters of C# were developers that came from C++ (on the Windows platform) along with some developers that came from Java. That’s no longer true.  College grads (since 2002 or so) are using C# for their first professional programming experience. Others are coming from VB, Ruby, Python, or PHP. (I’m not claiming that C# is grabbing market share from all those languages; the migration happens in all directions.) It just wasn’t right to assume that every C# developer has C++ or Java experience anymore.

The poster child for dropping items is the original Item 41, where I advocated using DataSets rather than implementing IBindingList yourself. I didn’t rewrite this item because the obvious answer now is to use BindingList<T> when you need the IBindingList capability. If you were using DataSets for some other reason, pick some other generic collection type. There are many, and the options grew again in .NET 4.0. Those generic collections have better APIs (the type parameter means the compiler ensures type correctness), and better performance (boxing / unboxing doesn’t apply. It’s not often that it’s trivial to get better performance and better chances at correctness. Even in the 1.x days, I didn’t advocate using DataSets are part of a service API. That was and still is a painful choice.

There’s also been many enhancements in the .NET framework that mean there are better data solutions. LINQ, along with the query syntax pattern (See Item 36 in More Effective C#), means there are much better ways to work with data in .NET 4.0.  Chapters 4 and 5 of More Effective C# discuss these important techniques. The entity framework has matured, and is a better way to handle data transfer between layers and machine boundaries. (I still need to look more closely at the latest EF, I know some of the changes, but not all).

All in all, I’m happy that the second edition did preserve quite a bit of the original advice from the first edition. The C# language has grown, and there are better tools in the C# toolset. It was clearly time for an update that represented the changes in the C# language, the .NET framework, and the C# community at large.

Posted 04 December 2009 11:38 AM by wwagner | 1 comment(s)

Filed under: Effective C#, C#, C# General, DevCenterPosts