Visual Studio 2010 Best Practices

Most of my spare time in the last few months has been taken up by writing Visual Studio 2010 Best Practices.  This has now been published and is available through publisher (no longer pre-order) at http://bit.ly/Px43Pw.  The pre-order price is still available for a limited time.  Amazon still has it out of stock; but $39.99 at http://amzn.to/QDDmF7. The title of the book really doesn’t do the content justice.  Least of which is “Best Practices”.  Anyone who knows me should know I don’t really like that term.  But, hopefully those looking for best practices will read the book and learn from chapter … Continue reading Visual Studio 2010 Best Practices published

I often compare software development with building houses or woodworking.  I sometimes even compare software development with the vocation of electrician.  In each of these other vocations, craftspeople need to go through a period of apprenticeship and mentoring before being “allowed” to practice their craft.  In each of these vocations there are a series of rules that apply to a lot of the basics of what what they do.  With building houses there are techniques and principles that are regulated by building codes; with electricians there’s techniques and fundamentals that are effectively regulated by electrical codes and standards.  It’s one … Continue reading Software Design and First Principles–Part 0: Concepts of Object Orientation

NUnit introduced a feature called Explicit Tests (a long time ago, I believe) that basically mean a test is considered tagged as Ignore unless the test name is explicitly given to the NUnit runner. This is useful if you have tests that you don’t want run all the time.  Integration tests or tests highly coupled to infrastructure or circumstance come to mind…  But, it’s difficult to automate these types of tests because you always have to maintain a list of test names to give to the runner. The ability of NUnit to run explicit tests aside, I don’t generally use … Continue reading “Explicit” Tests with Resharper

I was having a  conversation with a client recently and the topic of “11th hour” came up.  He seemed to think it wasn’t possible to deliver a software project without some sort of “11th hour” panic.  I disagreed I disagree because I’ve done it on small and large projects.  Don’t get me wrong; it’s very easy to lose sight of things and easily get a project into a state where “11th hour” panic is inevitable.  But, it’s not something that can’t be avoided. One of the problems with software projects, it seems, (and with other projects, I suppose) is losing … Continue reading Criteria for Success

Given economics, time constraints, resource limitations, etc.; you can’t write all the functionality for a given solution for a single release.  Even if you weren’t limited by these constraints, you’re likely to get changing requirements as development progresses and everyone learns more about the software under development. It’s fairly easy to prioritize what is developed and what isn’t.  You simply develop only what you need (see YAGNI).  But, how do you manage adding new functionality without causing undue grief?  One way is to only make additive changes to the code.  For example, let’s say we have the method create CreateRequestPacket … Continue reading Evolving code over time

The schedule for DevTeach 2009 Vancouver has been announced (http://www.devteach.com/).  There’s lots of great software development sessions from some of the leaders in our industry. If you’re planning on improving yourself, this is the conference to go to.  Not only can you attend excellent sessions; but you can hob-knob with the presenters and pick their brains. If you have a friend or co-worker who’s interested, there’s a limited-time two-for-one offer for an even better price: http://www.devteach.com/Register.aspx

[Edited 14-Mar-09: clarified generated code SCC practice] This edition provides SCC vocabulary and some more practices that make development life easier. VocabularyTrunkThe root of the project or database.  Sometimes called mainline or baseline; depending on the SCC structure, this is where most of the development occurs.MainlineThe root of the project or database.  Sometimes called trunk or baseline; depending on the SCC structure, this is where most of the development occurs.BaselineThe root of the project or database.  Sometimes called mainline or trunk; depending on the SCC structure, this is where most of the development occurs.TagA snapshot in time of the system … Continue reading Developing with Source Code Control – Best Practices Part 2

There’s a well-known anti-pattern called the anaemic domain model[1][2].  This anti-pattern basically says domain entities, chronically, have little or no behaviour (remember, object-oriented design is about attributes and behaviour). It should be obvious that a domain model that isn’t truly object oriented is a domain model with a problem.  But, let’s look at other reasons why the Anaemic Domain Model is an anti-pattern.  Your Domain is the nexus, the essence, of your system. An anaemic domain model is basically a reporting system.  Each “Entity” becomes, essentially, a query.  This is fine, reporting systems are necessary and prevalent.  But, to shoe-horn … Continue reading A Upcoming Pandemic of Domain Anaemia

References http://en.wikipedia.org/wiki/Revision_control  

This post will detail some first principles about source code control (SCC) and provide what I consider the most basic of practices that every dev should follow. What is SCC?SCC provides developers the ability to keep a history of their changes.  SCC allows developers the ability to group file changes together with an annotation. SCC allows developers the ability to get back to the state the project was in at any given point in time, arbitrary or specific (Beta 1, RTM, etc.).  SCC provides development teams the ability to more easily work on the same files at the same time.  … Continue reading Developing with Source Code Control Best Practices Part 1