OK, I don’t know Java well enough to give it a eulogy. It may not even be actually dead. But the end is definitely near. First, Oracle bought it, surely just to destroy it so the IBM can’t make money off of it anymore. Or maybe not. Maybe Larry actually wants it to live. Maybe the Oracle thing doesn’t even matter.

The strongest evidence I have that Java is dead – we (the .Net folks) don’t steal from it anymore. Much of the best things about .Net (including C# itself) have been stolen from Java. And that’s a good thing – that’s what progress is all about: taking ideas and expanding upon them in a different setting.

Now we steal from Ruby instead. We steal the ideas and language idioms. We steal the framework concepts (ASP.MVC look like Rails to anyone?). We steal the tools (how many Cucumber clones do we really need? Just use StoryTeller – its much, much, much better for matching how we roll in the .Net space…). And all of the cool kids aren’t jumping ship to Java world, they are becoming Rails heads.

Java brought some great things to the table – not having to manage memory being the biggest, although as a staunch NHibernate fan, I’m grateful for it for bringing about the rise of the ORM. It also brought some dreadful things – boilerplate for the sake of boilerplate (you know I’m talking about you, EJB). But on the whole, it was a great thing. It wouldn’t have led to the creation of C#, my drug of choice (although that probably had as much to do with Sun’s lawyers as it did any pure motives).

So, the question becomes, given how tightly coupled our histories have been, what does all of this mean for .Net? I think its clear – C# continues to get the best ideas from the rest of the language world incorporated and become more powerful. I just hope that it doesn’t end up being so convoluted in the process that it becomes unusable.

In this obligatory post, I’d like to make my New Year’s resolutions for 2011:

• Seriously learn a new language or two. I’ve started diving into some Ruby, but F# is also something I want to spend some time with. I don’t want to leave .Net, like all of the cool kids are doing these days, but I can see that C# is trying to become more like these languages and so I know that learning them will help me become a better C# programmer. Regardless, this nugget of advice from the Pragmatic Programmers is one I have not been keeping up with and so I must do better.
• Present at more events. 2010 marked the first time I’ve spoken outside the Pittsburgh area (thank you NOVA Code Camp!). Its fun to meet people in different communities that have completely different experiences. I want to do more of it.
• Really get serious about writing. I’ve been blogging in various forms for 7 or 8 years now. Extremely sporadically. I’m better at Twitter (but of course that doesn’t take anywhere near the effort). I actually do a fair bit of writing in my day job that could easily be cleaned up and turned into  blog posts. I just need to do more of it.
• Spend less time reading, and more time doing. I don’t think that requires any explanation.
• Keep up with my health. Last year I was diagnosed with type-2 diabetes. I’m lucky enough to have it under control with pills and weight management. I can even be bad occasionally and eat some cookies (which I did entirely too much over the holidays). But there is a silver lining – it caused me to wake up and realize what I was doing to myself, and through better eating and exercising regularly (I get to the gym at least once a week – better than I was, but still in need of improvement) I’ve lost 30-35 pounds. And I just feel better.

I had a good time at the Northern Virginia Code Camp. Had the chance to meet some people I only really know via Twitter and got to catch up with others. I’m glad they let me present – my “I’ve Sprung a Leak” WinDbg 101 talk had a good sized crowd that had good questions and feedback. I know I learned a few things along the way.

The Software Craftsmanship panel discussion for the Community Megaphone podcast was also interesting. I’ve never had the opportunity to do something like that before. I hope my passion for the subject came through without a lot of “jerkiness”. Sometimes I get a little carried away… I’m glad Andrew and Dane invited me.

NOVACC was actually a bit nostalgic for me – I attended my first code camp ever at the first NOVACC. They are always so well run – taught me a lot for when we got around to doing them in Pittsburgh. In fact, I took some notes for things we can steal to improve our camp. Thanks to Hal Hayes and the volunteers for putting on such a great event.

Fellow Pittsburgher Hemant Singh was also presenting, and I caught his session. He explained WPF styling. I wanted to finally see Dane’s session on Entity Framework (just to see how the other half lives), but by the time I realized he was doing it it was half over. There were other talks I wanted to see but couldn’t due to scheduling conflicts.

Lots of good conversations and discussions with other attendees. I found out Brian Lanham from Roanoke is a fellow Penn Stater and is actually working on getting a user group off the ground in Altoona. I’m definitely going to have to find a chance to present there.

I promised those attending my talk at NoVA Code Camp 2010.2 that I’d post links to the resources I’ve found for using WinDbg, especially the SOS commands. Here you go!

Download: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

My “Getting Started” blog post: https://erickepes.com/2009/11/21/obtaining-a-memory-dump-to-diagnose-memory-leaks/

SOS Debugging Extension: http://msdn.microsoft.com/en-us/library/bb190764.aspx

Brock Reeve’s sample code (what I used in the demo): http://brockreeve.com/post/2010/02/10/Windbg-and-SOS-for-Visual-Studio-NET-Weenies.aspx

Tess Ferrandez’s blog (lots of good stuff): http://blogs.msdn.com/b/tess/

Other interesting links:

• http://blogs.msdn.com/b/johan/archive/2008/01/23/using-windbg-advanced-commands.aspx (Info about .foreach)
•  http://naveensrinivasan.com/category/windbg/

Why do we in software dev ask permission to improve tooling or improve the code? Does your landscape firm ask permission to sharpen blades? – Troy Tuttle via twitter

I know its very much an in vogue thing these days to call one’s self a software craftsman, but I’ve been doing it for a while now. Not because I’m an arrogant snob (although I’m sure that many see me that way ). No, instead, because to me, craftsmanship represents what has been missing from our industry.

We like to pretend we’re engineers. In fact, my employer thinks I’m a Technical Lead Software Engineer. I’ve resisted this title all of my career. There is no formality, no cohesive body of knowledge, none of the other trappings of engineering in software development. I don’t think we’ll get there anytime soon, either. We’ve been building software for a bit over a half a century. In the Western World, engineers have been building bridges and marvelous structures since the Romans, the Greeks, even back to the Egyptians. Thousands of years ago. Even on Internet time, we have a lot of catching up to do.

I’m not a programmer, either. That’s extremely limiting. I do more than just sling out some code. I’ve liked the title Developer. I think it represents what we do. We do whatever it takes to develop good software. Whether that’s writing code, drawing diagrams on the whiteboard, discussing the best ORM in the hallway, executing a test plan – that’s what we do.

To me, the Software Craftsmanship movement is the next phase in that evolution. Its about refusing to compromise our principles without a full discussion of the consequences. Sure, I’ll crank out that feature in half the time I told you it would take. But when we come back to add to it next release, it will take that time you cut from my budget just to get it to the starting point. And that can be fine.

That’s where craftsmanship has been taken too far. At the end of the day, we’re paid to ship software. If the code underneath that shiny UI is total crap, but the application does what it needs to, we’re successful. There’s nothing wrong with that. As long as its acknowledged that the necessary structure to take that application to the next level is not there. The problem is, someone will say that we only just need to add this one feature, and then we can take the time to fix the plumbing.

But someday never comes. Or it comes years later, when its clear to everyone that the current architecture is holding us back. Only then somebody decides we need to fix things. And so we undertake a re-write. Which takes longer than anyone ever budgets, because the requirements are never well specified – its always, just make it do what it did before. And add these 5 features while you’re at it.

Maybe the first version is based on a solid architecture. The code is well written and even obeys all of our coding standards. Its been peer reviewed or maybe even pair programmed. But you don’t have any automated tests: no unit tests (or maybe a paltry 10-30% coverage), no feature/functional/acceptance tests, no automated UI tests. So as you move along, you make changes that ultimately break some existing functionality, and nobody discovers it. Until “integration testing”, which is another failure condition. Or worse, there never was even a manual test case to cover the regression and the defect isn’t found until you are in the field, or the web site has gone live. There are a myriad of ways to cut corners on software…

Software Craftsmanship means standing up for solid software. It means only allowing shortcuts to be taken when the stakeholders understand the consequences. Taking on technical debt only with the full understanding that you are doing so. Its important to not stand in the way of shipping software with debt as long as it’s a conscious business decision. It could make or break the company. But remember that unless the company is prepared to pay the extra costs associated with that debt down the road, that could also break the company.