May 2008 Blog Posts
Jeremy Miller has written a good article on the Open/Closed Principal and friends for MSDN. Read it now. (NOW!)
The waterfall model provides a nice clear answer to the question of when you do the design. You do it up front, after you've done your requirements analysis and before you've done your implementation. This answer is simple, clear, and completely and utterly wrong. Project managers tend to like it because it's easy to put on a Gantt chart but the connection between this model and reality is tenuous at best. There are in my opinion two primary problems with attempting to do all your design up front, and these problems are interlinked. Firstly it ignores that design permeates all...
For my discussion of application architecture I'm creating an example application to demonstrate some of the concepts and tradeoffs involved. The problem I've chosen is an online movie review site based on the movie review strategy I've recently adopted. As the first step I'm going to define some requirements. Normally these are sourced from the business using requirements analysis. However in this case I'm just going to make them up. This means that they will be incomplete, inconsistent and wrong in places, which makes them indistinguishable from real requirements. In practice requirements tend to change over time due to shifting...
I saw Indiana Jones IV this evening. This movie has caused me to abandon a single dimensional rating scale. More on this later. First the review (some spoilers included). The fourth instalment of Indiana Jones is for the most part an entertaining comedy adventure movie. The expectations of over the top action are met with (amongst other things) a fight in Area 51 (watch for the cameo by the Ark of the Covenant) which ends with Indy surviving a nuclear test blast inside a lead-lined fridge, fights surrounded by man-eating ants and a highly entertaining and highly implausible fight through...
Build vs. Buy* is a question faced by any significant development effort. Existing third party systems are available for most business functions, such as finance, content management, portals, CRM and many others (I'm not going to discuss the pedantic cases of operating systems, web servers and the like). For these kinds of functions buy is almost always the better alternative. My plan is not to discuss what kind of criteria you should make this evaluation on. Rather I intend to discuss the effects of buying a third party system will have on your application architecture. For the purpose of this...
The beta for version 4.0 of my single favourite development tool is out. Things are looking pretty good, but on balance it's not ready for production use yet (at least when I'm being paid to code). I installed it on my primary development machine earlier which went well. There are still a few glitches that make me reluctant to commit to it over version 3.1: It threw exceptions when I tried to use format on a particular file. I thought this was due to it being locked in source control, but I checked it out and the behaviour continued...
File comparison tools are something that needs to be in the toolkit of every professional software developer. They're essential for working with other developers to integrate changes and make it possible to track changes over time (in conjunction with source control). Most source control systems come with basic comparison tools but these tend to be fairly limited. This has lead to the development of a number of replacement tools. Of these my current favourite is Scooter Software's Beyond Compare. There are many things to like about Beyond Compare. This starts with the price which at US $30 for a single...
The term "happy case" refers to making the assumption that everything proceeds correctly and as expected when working through a use case. Happy case is important as it defines the desired behaviour for the use case. In production things will not always proceed correctly. Being aware of this and developing your application to deal with it is one of the differentiators between amateur and professional software developers. I've previously discussed that sometimes your application just needs to die. This applies to errors that are unrecoverable. It should not apply to minor errors or unusual but valid conditions. Your application crashing...
Apparently one of my posts is currently the top result on Google for: 2008 ghostdoc change keyboard shortcut Unfortunately the referenced post doesn't actually specify how to change the shortcut. So in the interests of serving the great web browsing public I shall now explain how to do so. Of course you could just look in the Ghostdoc help but that would be logical and entirely non-geeklike. The secret (such as it is) is to use the Visual Studio options. The Keyboard options give you the ability to assign new shortcuts for just about everything. Type in "ghost"...
In order to achieve useful outcomes software must comprise a variety of behaviours. These behaviours can be grouped into particular areas of concern. In developing line of business applications (and generally across a number of application types) there are three common areas of concern; presentation, business logic and persistence. Presentation concerns the display of information to the end user and the handling of user input. Business logic is concerned with the handling of the business functionality for which the application is constructed. Persistence concerns the storage and retrieval of the data on which the application operates. Applications may have other...
The ABC news site currently has a video "Australian Miss Universe contestants give their verdict on the Budget". This is the kind of moronic "celebrity as a substitute for expertise" nonsense I'd expect from Today Tonight when they're running low on dodgy builders and unlikely diets. It's not what I expect from the public broadcaster.
Note to evil, evil telemarketer scum. The phrase "courtesy call" will cause me to hang up immediately. It's not a courtesy to tell me about your seminar. It's just intrusive and irritating. Also, if you have to advertise your investment opportunity via telemarketing I'm going to assume that's because it's of sufficiently low quality that no one but gullible fools who buy stuff advertised via telemarketing would ever invest in it. Time to sign up for the Do Not Call register.
Code must be running in order to hit breakpoints. Stupid non-psychic debuggers.
In my previous post I discussed a variety of desirable attributes in an application architecture. I made the point that although you should make some basic concessions to performance (such as avoiding chatty communications) optimising for performance without being able to measure the results is generally sub-optimal. I made the point that in most cases "good enough" performance is generally all that's required, beyond which additional performance gains have no benefit. However, what about cases where this doesn't hold? How do we address problems where we need to be able to add additional performance to an application over time? What...
In discussing application architecture we need to start with an understanding of what we are looking for from the architecture. Architecture is additional work over and above simply writing code. We therefore need to understand the justification for doing it. Additionally if we wish to do it well we need to understand our goals for the architecture so that we can best meet them. All applications have at least an implicit architecture, even if this architecture can be best described as a "towering pile of hacks". Therefore we must consider what thinking about architecture explicitly gives us over this base...
There are few things that can guarantee failure of your project more successfully than a bad architecture. The truly insidious thing here is that you may not realise the scope of your problems until your first release is out and you're left with an instant legacy disaster that will be a nightmare to maintain and impossible to extend. Here are some semi-fallible warning signs that your architect may not be quite ready for the challenge of building your application. Your architect has never maintained a system before Maintenance of an application is a very different thing to building a new...
Brian has begged repeatedly (OK, asked once) for me to mention the Perth SQL Server User Group, at which Dr Greg Low will be presenting this Wednesday (May 7th) on Dynamic Management Views and Custom Reports in SQL Server 2005. That means little to me, but you SQL Server types have at it. Full Disclosure: This session is sponsored by my employer (Change Corporation) whom I do not speak for in any fashion.
This Thursday (May 8th) the Perth .NET Community of Practice session is on Occasionally Connected Systems using SQL Server CE and SQL Server Express presented by Dr Greg Low, about whom my colleague Brian Madsen says many good things. I'm particularly interested in this presentation because my view of SQL Server is primarily as a bit bucket that is an implementation detail of individual applications but not something I'd want to use to share data between applications (primarily for reasons of the coupling between applications this tends to cause). Exposure to alternate viewpoints and new information on this topic should...
Visual Studio gives developers two primary options when in comes to compilation: Build and Rebuild. Build looks at modification dates and compiles only those things that have changed or have had their dependencies change. Rebuild ignores this and just compiles everything. Build is allegedly faster, because it can potentially skip a lot of work. There's only one problem with this: Every now and then it completely screws up and either produces incorrect output or fails to compile. Strangely, I have a problem with this. I long ago lost track of the number of times team members have had a problem...
Following the recent failure of my dishwasher, my water heater has now decided to spring a leak. From the place where the electricity goes in. Again. This time I unfortunately don't have a way to tenuously link the failure to software development. There is however a non-zero chance that cold showers are going to give me fatal pneumonia. Which is something to look forward to.
Unfortunately it appears I'm going to have to get Batman Begins and watch it again to answer this question. There was no part of the movie which I didn't like. OK, the plot was entirely predictable but this is not a movie you see for plot twists. It had a lot of humour, things went boom and the special effects were well done. Also the casting of Robert Downey Jr. was (as has been mentioned many other places) brilliant. To those of you who didn't come see it today (you know who you are): Shame on you. To the public...
Architecture in software development tends to be one of those ambiguous terms that means many things to many people, and rarely the same thing to anyone. There are some things that are clearly architecture, some that are clearly not, and many that live in a grey world of ambiguity. In this respect it's much like service, the clear current leader for most ambiguous prevalent term in computing. Modern enterprises need architecture at the enterprise level in order to build IT systems that are effective and coherent across the entire scope of their business. This is high level architecture where you...
I've decided to trial using Feedburner to see if it the stats are interesting and useful. This of course means I'm tracking your every move. So behave.
There are many characteristics on which a software developer may be evaluated. Many of these related to specific areas of expertise such that a developer may be an expert in a particular field but have no competence in other areas. One characteristic that is in constant demand across all software development is professionalism. Unfortunately this is far from universal. Professionalism is all about attitude and behaviour. For me, it covers a few key areas such as integrity and commitments to quality and self-improvement. Integrity is a cornerstone value that covers honesty in dealings with clients and coworkers. Professional relationships are...