Although firmly seated in the .NET industry, I try to keep tabs on the other camps to see what they’re up to. A lot of people are now really starting to master what we today call agile software development. They’ve harvested the benefits agile has had to offer – and they want more. A profound example of this is the concept of continuous deployment(read his follow-up too), as explained by Timothy Fitz:

“The high level of our process is dead simple: Continuously integrate (commit early and often). On commit automatically run all tests. If the tests pass [automatically] deploy to [production.]”

Johannes Brodwall has a thoughtful post on what the future of software development may look like. His vision is a mainstream adoption of continuous automation: continuous testing, distributed source control, continuous integration, continuous deployment.

I’m left wondering – where’s the .NET community? Are we lagging behind the curve? If you’ve not yet picked up on the concepts that we’ve been preaching about the last few years, such as continuous integration and unit testing, you should be getting worried about being able to keep up – the leaders of the pack are already moving on.

This autumn, I’ll be giving a series of talks at the MSDN Live conferences across Norway, where I’ll both be discussing and demonstrating some of the ways we can push the envelope with agile software development within the .NET space.

Last weekend, the Channel 9 guys released an open source blog engine called Oxite, built using ASP.NET MVC. This went by fairly unnoticed (for me at least), until Rob Conery shared his thoughts about it over on his blog earlier today. Not long after his post, Twitter was buzzing with opinions - here are what some people have had to say about Oxite so far:

“wow, the Oxite codebase is an example of the MVC anti-pattern. WOW” - @DerikWhittaker

“Oxite: No DI/IoC, not at all SOLID, i.e. typical MS sample software :)” – @mikehadlow

“Oxite will be used by developers first, and will introduce initiates to all kinds of irresponsible design” - @bellware

“Oh dear, look at Site.Master in Oxite.” - @chadmyers

“Oxide fails as both an example and as an application. It's damaging for us guys trying to push the methodologies that mvc aids” - @chriscanal

You can catch up on the entire discussion using this Twitter search query. Erik Porter (@HumanCompiler) is one of the guys behind Oxite and has been doing his best to defend it – I almost feel bad for the guy :)

I think what worries everyone the most is that since this is something released by people who work for Microsoft, it will get a lot more attention than it would merit on its own. Through its connection to Microsoft it automatically gains credibility, and novice developers will falsely look at Oxite as some kind of ‘Microsoft-approved’ guidance on how to build (ASP.NET MVC) applications. Given the current state of the codebase, these developers will be led astray, and potentially pick up bad practices and anti-patterns.

It shall certainly be interesting to see how all the feedback will affect the future development of Oxite.

On Tuesday last week, Microsoft hosted the final event of the MSDN/Technet Live live tour in Oslo, and I was there to do my Introduction to ASP.NET track. 1200 developers and IT professionals showed up and responded with an impressive amount of noise when Rune Grothaug and his Technet sidekick (don’t know your name, sorry!) went on stage to fire up the crowd and announce the keynote holder – Steve Ballmer:

Steve held a great keynote where he talked about the future of our trade and how Microsoft envisions it (Software + Services, cloud computing, virtualization etc). The amount of energy and enthusiasm he has is impressive, to say the least.

After giving his keynote, us speakers and some representatives from the different .NET user groups got to briefly meet and take a picture with Mr Ballmer:

All in all, it was an awesome day that won’t be soon forgotten :)

Just over 18 months have passed since this blog launched, and this is the 100th post. Knowing that I spend anything from one to four hours (and sometimes even more) researching and writing up a single post, you can imagine how much time keeping an active blog demands; if you’re a blogger yourself, I’m sure you know.

That said, I couldn’t imagine not keeping a blog – I’ve always enjoyed writing and I’m investigative by nature. And of course, the rewards not only in terms of the learning value but also the recognition and feedback from visitors, subscribers, trackbacks, links etc play a part as well :)

A Developer Manifold

Its interesting to see how community-oriented us developers are becoming. We read blogs, write blogs, chat on Twitter (@fredrik_k), discuss on Stackoverflow and generally spend a lot of time interacting with each other. Some may see these things as a productivity killer - and from time to time it cannot be denied that I find myself using them as an excuse to procrastinate, but mostly I think these tools significantly boosts not only our knowledge but also our inspiration, effectively improving both the quality and the quantity of the work we do.

So, here’s to a hundred more posts! I’ve got some exiting stuff in the pipeline (well, I think so at least :p), so watch this space :)

Steve McConnell, who knows a thing or ten about software development best practices, posted some excerpts from a white paper he and his colleagues at Construx Software wrote titled "Software Development's Classic Mistakes 2008". They've collected statistics through a survey and come up with some interesting data on the most common and most severe mistakes that we software developers make. Go check it out.

One thing that immediately struck me, was that none of the top ten mistakes listed were really unexpected. Overly optimistic schedules? Unrealistic expectations? Feature creep? It worries me that these are mistakes that we know about, hear about all the time, and still can't help but make, over and over again. As Steve writes, "many of the mistakes in the survey do indeed deserve to be called "classic" mistakes. I find it interesting that 8 of the top 10 mistakes in this year's report were listed in a book I published in 1996. If these mistakes were classic in 1996, they're even more classic 12 years later!"

One of the comment on the post really struck a chord with me. "Andy" reasons that we treat software development too much like art,  as opposed to engineering (emphasis mine): "If the focus was on engineering, [then] learning best practices, and educating the workforce on topics like estimation, project management and SDLC, would be more common. (...) You don't see construction companies figuring out how to build buildings or bridges on their own."

Too often I see developers dismissing the notion of patterns and best practices; they see it as shackles that will only serve to hold their creativity back. I'm not saying that they're the answer to everything - there'd be no innovation, then. After all, software development is still a young discipline, and there are lots of things we've yet to work out how best to. But learn a thing or two from the millions of feet who have tread the path before you, then go off and change the world.

Even the best of us makes mistakes. And sometimes, we don't notice 'till it's too late to turn back. This weekend, I'm working on refactoring/remodelling a fairly large feature which is part of a big legacy application at work. A seemingly innocent design decisions made years ago, has come back to haunt me, making things that should be easy difficult, and things that should just work, well, not work at all.

Years ago, the legacy application in question was party ported from unmanaged C++ into .NET. Not only that, it was ported from a flat file-based application to a database-backed application. Naturally, this created the need for a data access layer. An extension for ADO.NET was written, leveraging DataSets with all kinds of neat auto-magic features. Years of joy followed (well, disregarding the constantly growing list of reported bugs, of course).

Fast forward to present day, and finally we're getting ready to start killing off at the last bits of that old C++ code. Not only that, but we're taking on the momentous task of refactoring and cleaning up the entire application using modern-day architecture and general good-practice idioms.

Something != Nothing

Okay, so there I am, happily building a sparkling, new domain model with all the right entities in all the right places, happily staying on track with the help of Eric Evans excellent Domain Driven Design book. We've decided to use Developer Express' eXpress Persistent Objects (XPO) as our O/R mapper this time around, which among other things lets us take advantage of all the lovely new LINQ stuff (which, by the way, makes abstracting away the data access layer in unit tests a joy - look out for a post on that topic soon). So, all my tests are dressed up in their finest green and all is joy. Until I put together a simple test application to test things out against a real database... BAM! XPO blows up, complaining that the referential integrity of the database is compromised. Say what? I poke around for a bit, and quickly realise that even though the database which was modelled all those years ago and has incrementally grown to several times it's own weight since then is normalized quite well, there's something weird about these foreign keys... They've all got NOT NULL constraints. Well okay, so that might not be such a big problem in and of itself - but considering that several of the relationships are 1 <-> 0-1, this clearly poses a question of how we represent the case where, say, a Person doesn't own a Pet; what do we set the Person.PetID column to? Well, in our case, 0 is treated as the 'magic' value meaning 'nothing'. Trouble is, that's really a lie and the database doesn't know it, so it thinks that our Person really does have a pet - the pet with ID = 0. No Pet with that ID exists however, so when XPO tries to load the Person, it can't find it's Pet. Time to call the neighbours and organize a search party.

Obviously, in hindsight it makes perfect sense that the PetID column should be nullable, so that any Person who doesn't own a Pet can have Person.PetID = NULL. The difference may seem insignificant; it is however a huge difference semantically, and say one thing for computers, say they're pedantic about semantics.