Have you ever found yourself spending more time trying to learn patterns than actually designing or coding your application? It's easy to do. With the maturation of .NET, suddenly everywhere you look you see presentations, books, and blog posts talking about this pattern or that pattern, each asserting that the other is inferior for some obscure reason. And you, being the mature .NET developer that you are, follow these conversations, desperately trying to find the "magic" patterns that will make your next project perfectly maintainable, easily extendable, and consistently scalable from the get-go. I know, because I've been there.
Now, there's nothing wrong with patterns. In fact, they're very helpful in moderation. They allow developers that implement code to benefit from the long winded thinking done by developers that have time to think about the absolute best way to do things. The problem, though, is that there is no "absolute" right or wrong way to do things. There are better and best ways to do things for specific scenarios (as learned from collective experience), but no one can tell you the "right" way to write your application. And left unchecked, it's easy to wander down the rabbit hole of pattern research and get lost in "Patternland."
So, I'm coining (or re-coining, as the case may be) the term "Potluck Programming." Or if potluck's aren't your thing, UWWFY™- "Use What Works For You."
The concept is simple, but essential. When setting-out to improve your development with patterns, find patterns that help solve problems you have (not problems you think you'll have- YAGTNI), find patterns that make sense for your project (not every project is a huge enterprise, super complex application with the need for IoC containers), learn the patterns, and then start writing some code!
And don't feel guilty if you don't follow the pattern 100%. I like to quote the wonderful piece of 21st century cinema Pirates of Caribbean to explain this. In the words of the digitally-enhanced (or is it degraded?) Captain Barbosa:
"The patterns are more what you'd call guidelines than actual rules. Arrr..." (loosely quoted)
Patterns are supposed to help you write code in a way that avoids the problems other developers have encountered, but they're not supposed to be a paint-by-numbers guide to coding your application. Use what works for you and don't let patterns bog you down. And if you find yourself getting bogged down, step back and write some code. If nothing else, that will help provide more context for the pattern so you can learn it more quickly.
Hopefully this simple advice will help you avoid the productivity drain that pattern research can become. Have you ever found yourself crawling down the pattern rabbit hole? Sound-off in the comments.
It is amazing to me how quickly the the noise surrounding cloud computing has grown. Overnight cloud computing has become a mainstream talking point with everyone postulating how enterprising start-ups and lumbering enterprises will use the emerging technology in software projects. InformationWeek is running cover stories on cloud computing, Microsoft is touting their new cloud services, and even Apple is getting-in on the game with MobileMe. It seems cloud computing has replaced software as a service as the most popular water cooler talk.
And if you ask me, cloud computing is much more interesting and much more able to be a "game changer" than SaaS ever was. SaaS always seemed like a fancy way to describe hosted applications. It really wasn't anything new- eBay has been providing SaaS auction services for years- just a change in focus and maturity. Even as a young entrepreneur, I built career fair management software that I sold to customers from my hosted environment- who knew I'd "stumbled" on the SaaS business model.
Cloud computing, on the other hand, is substantive. It is bringing real, game changing technology to the table that is going to enable a new generation of entrepreneurs to capitalize on never before possible access to cost-effective, low-risk scaling. In other words, cloud computing is going to give little ideas the ability to reach big audiences without millions of dollars in financing. That's an exciting development if you're like me and you're always looking for ways to bring your ideas to life without investing your
wife's life's (Freudian slip) savings.
The impact of cloud computing on .NET developers should be big, too. I fully expect to see cloud service integration become standard practice in .NET applications and a new crop of tools to emerge that will help developers with the challenges cloud computing presents (network latency, dynamic scaling, etc.). At the component level, I wouldn't be surprised to see new data controls that enable you to easily bind to cloud data or ORM tools that make managing scalable data in the cloud as easy as managing a single instance of SQL Server. Unlike SaaS, cloud computing will have an impact on your daily developer life.
For those of you less interested in the business impact of cloud computing and still struggling to see its purpose, there are clear consumer driven applications of cloud computing sprouting-up at the world's major software producers that should provide some clarity. Take, for instance, the "could drive." The long awaited drive that lives on the Internet, enabling users to save their files on their computer and access them anywhere, anytime.
Microsoft and Apple are prepping services that bring this dream to life. Microsoft's LiveMesh is a software + services approach that uses a small client install to enable seamless file synchronization between all of your devices (PC, Mac, and Mobile). Similarly, Apple's iDrive, previously part of .Mac and now a member of MobileMe, enables you to save files on your Mac and easily access them on the web or on another PC. Apple provides its software integration at the OS level, but end result is very similar to Microsoft's and both offerings rely on cloud services and storage to deliver the anywhere, anytime data access.
With Microsoft's offering in particular, developer's have a unique solution to one of the biggest problems facing Silverlight: no local file system access. How do you build web-based replacements for client-apps if you can't save files to the local file system? Live Mesh. Using the Live Mesh APIs, you simply save an user's file to the cloud and the cloud in-turn syncs the file to the desktop. It's roundabout, sure, but it's also compelling since this approach should mean the file is always available to your online app, even if the user travels to another computer.
But where's Google? Long before LiveMesh and MobileMe were twinkles in a marketer's eye, Google was rumored to be building "GDrive," a Google-powered cloud storage service that you could use to backup and access your files. Since the early rumors, though, Google has been mum on the GDrive topic, allowing both Apple and Microsoft to beat the perennial cloud proponent on what should be their own turf. It is bizarre that Google appears to be a late mover in the cloud computing space, but I think it's safe to bet Google will eventually make their move.
Until then, the work by companies like Microsoft, Amazon, EMC, and others make it clear cloud computing is here to stay, and in a big way. And while I don't think the term "cloud computing" will last forever, the use of the Internet as an applications platform will.