After a short gap…

I’m back blogging…

well, I at least have good intentions to do so.  This post is mainly to see if windows live writer works ok to post to my blog!

Lets see…

Resharper 4.0 .NET 3.5 Viemu

I'm loving it!

Resharper 4.0s support for the new language features is great. So far I haven't really had any problems with it. There's a few UI keybinding errors, it did crash when I tried to customise the live templates, but for the general grunt work of programming it's fantastic.

Viemu

ViEmu is a Vim plugin for Visual Studio. I first came across it in http://www.iunknown.com/

It seems to be gaining a little bit of popularity, I had spent a bit of time a while back learning the basics of Vim so I installed it a while back, but it seemed to clash a bit with resharper so I backed out of it again. However, I have recently gone back to it and have remapped some of the resharper stuff.

In fact one of the best things you can learn with Resharper is using the Alt-R (which activates the menu item) and using the keys to drive it from there. It's surprisingly effecient, as is Vim style editing.

Now one of the the things I did to make Vim editing a whole lot better was turn my CapsLock into Esc. ( using ScanMapper from http://www.sellsbrothers.com/tools/ ) I usually disable capslock anyways because its a completely useless key, so it was great to find a good use for it.

For those of you who might be a little confused why anyone would want to use Vim style editing (it is a little bizzare). Once you get the hang of keyboard comboing (much like resharper) you can edit very efficiently. You definitely have to spend a fair bit of time teaching yourself the basics. (worth getting something like gvim to play around )

Anyways, ViEmu is pretty good, definitely worth trying if you want to multiply your resharper jedi powers in another dimension :)

I get Facebook now!

Chris Sells wrote a post on Time for some anti-social networking. Like Chris I really didn't get facebook.

But I discovered the point of facebook.....

The point of face book is to get your friends to stroke your ego.

by sending you hugs, voting you sexy, cute, compatible, saying nice words about you, choosing you as a valentine, taking compatibility tests, by sending you gifts or aliens, etc etc blah blah blah. 

Facebook is a web app for people with low self esteem.  Which in hindsight is a pretty good market to target!

Boost

For anyone who does C++, you should also be well aware of boost.  In fact, you should generally be using boost  (unless there are technical limitations why you can't,  eg embedded platforms, non standard C++ compilers).

http://www.boost.org

boost is essentially a large template library that makes all kinds of general programming a lot easier.    It basically extends the std libray.   It is also the testing ground for the next C++ language standard.  

The following are worth their weight in gold :-

boost::shared_ptr

boost::bind

boost::function

and lambdas

Being a template library it also means you don't have to link to a library, you just have to include the headers and at compile time its generating all the code directly into your software.  So it's dead easy to get started with it.

I mention it because I interview a lot of C++ programmers who have never heard of it.   

Prefer Design over Platform Skills?

http://martinfowler.com/bliki/PreferDesignSkills.html

as he describes it I would disagree with him.

For starters we are dealing with a human being, so its never as simple as pigeon holing someone. But putting that aside

Secondly it is about building teams.

The combination of having broad platform skills in one person and broad design skills in another is a fantastic combo to get to work togeth

Thirdly, I think design skills are about as hard to acquire as good platform skills.

fourthly, good platform skills people are actually really good at getting into new platforms if that is what the project is going to be using. They often like to get into a lot more of the nitty gritty than a generalist

So,  the deciding factor for me would probablly what has each achieved, how complicated was it, and what kind of skills gaps do we have on the team.   I'd expect both to have a willingness to learn new things.

Basics of software design

On the ALT.NET email list there was a question about how to present Agile/OO Design to peers. Much of the advice centered around presenting principles like OCP, SRP, Demeter, Liskov, etc. However, while its good stuff, I don't think it hits at the heart of designing software... Also in the world of postmodern software design I think that some of the old guiding principles need new interpretations :-)

This was my advice... ( which is pretty rough )


From my experience none of the so called "principles" are good starting points. They are secondary ideas that reinforce the main idea.

Separation of concerns is a key idea.
Secondly we want to Compose Behavior together.

So we want to TDD concerns.
We want to TDD composition of concerns

Identifying "Concerns" is about finding abstractions.

Finding a name for an abstraction :-
Having conversations to find key abstractions. Making sure you take more note of behavior and less on Nouns. (Nouns trip people up)
Refactoring common behavior to find abstractions and then naming it

Understanding Concreteness vs Abstractness
Understanding Cohesion and Coupling
Understanding the different levels of Perspective (conceptual, specification and implementation)

Then!

- Principles come in and reinforce ideas about abstraction, what a "concern" is, what composition is, how things should be composed.
- Design Patterns support abstract composition of concrete concerns.
- Things like DDD helps formulate the way you have conversations about "concerns"

Alternatives to OO

- Functional Programming has different composition mechanics but the same ideas of software design of separating concerns, finding abstractions, and composing software together.


To present this to people...

You need to show examples of it in action

Weapon of Composability

Further to my recent post on programming weapons and categories of said weapons.

Composability

This is probably the most lethal of programming weapons/tools. This is the idea you can join bits of software together to achieve some goal.

The easier it is to compose software together the more "powerful" the tool.

The most obvious of these tools are languages. The popular players in terms of composing software together are functional languages, OO languages, dynamic languages, and hybrids. Each approach the problem slightly differently. It's worth mastering a number of these. This stuff is fine grained control of how software joins up and does something interesting

Another tool of composobility is Frameworks. These allow the user to wield a lot of precreated software in a very controlled way. Again, these are bread and butter stuff for most software developers.

DSLs are languages that match a particular problem domain and often leverage both frameworks and languages to achieve its end. This allows for an easy composition of ideas in the context of a particular domain. Gainning lots of traction these days.

Software Factories. These are similar to DSLs in that they tend to allow you to compose framworks and languages together in very quick ways. Factories can cut across many domains. Essentially you dial in what kind of software you would like and it will spit out software that does it. Currently there tends to be a lot of tweaking and the resulting software can be overly bloated, but if there is a factory that matches the type of soloution you want to create then its going to compose a lot of software very quickly for you.

Wizards. Can be great for creating chunks of software. Kind of like mini factories. I think a lot more could be done with these. Mostly software developers have very little control over these. I think if these were a lot easier to customise or make context aware they could be a lot more powerful.

Operating Systems / Open Standards. Things like *nix have a very composable runtime system. There are also many open standards for how things should talk together all of which has tooling and support for creating said systems

Application Scripting. A peice of software which essentially provides a framework for controlling it

Application Plugins. A peice of software which provides a framework and/or open standard for writing extentions to it.

Editors are the ultimate tool for actually composing software together. This is probablly 80/90% playground of software developers. It is worth being a master of your editor. I feel it also pays to at least appreciate multiple styles of editor also.... Vim / Xemacs / (Visual Studio, Eclipse, IntelliJ )

This is but some of the composobility weapons we get to employ as software developers. The essence of being a good software developer tends to being able to create good designs / acrchtetures / structures that allow software to be composed easily and utilising the right tools for the job. The techniques for how to go about doing this comes under "thinking weapons". And of course all this gets pretty hard to do without "Validation Weapons" or "Transformation weapons"

Bad service from domains4less.co.nz (Don't use them!)

Two weeks in the process of registering some domains with domains4less and they completely screwed it up. They charged my credit card twice and they didn't register the domains! Its taken them ages to try and sort the problem out, last email they asked for all the registration details again!

So walking away from that one! The domains have been registered through another registrar.

My advice, never use domains4less.co.nz

Programming Weapons

In a recent email conversation with Rick Mugridge the topic of Agile tools came up.... Which got me thinking about what tools we make use of as software creators. And possibly more interesting, what the tools of the future might look like.

So anyways I came up with a number of categories of tools.

1. Composition
2. Transformation
3. Validation
4. Thinking
5. Collaboration
6. Ergonomic

Which I will talk more about soon....

Part of my thinking process was that there are some interesting correlations between software development and martial arts.

I see martial arts and software development made of the following

Weaponary - Tools we have at our disposal
Tactics - the coordinated and organised application of weapons
Strategy - A plan to achieve a goal using a set of tactics (including adaptable plans that change tactics)
Philosophy - A system of rational thinking based around what one believes to be true.

Being able to fight or create software comes from a holistic application of all these things.

In the world of "Agile" there are some shared "values" of software development. They feed in at the level of "Philosophy" giving some sense of the epistemology ( what knowledge is thought to be "true" ). However that is about it. From there Agile is expressed with many different Philosophies / Strategies / Tactics and Weapons. Some things get shared ( especially the more effective weapons and tactics )

Choosing to be "Agile" really doesn't mean a lot. Choosing to do Scrum or Extreme Programming is more useful. Often choosing to be "Agile" results in making choices similar to....

"Punching? yep sounds good, we'll do some of that"
"Kicking? well, that sounds a bit difficult, perhaps we'll do that later"
"Throws and Takedowns? Seem to be a waste of time"
"Grappling? Supposedly that's good, we'll do a bit of that"

Now we end up with a system where there is no guiding philosophy, strategies that are not cohesive, tactics and weapons that sometime work and sometime don't without much clue as to why.

I think it pays to gain mastery in one holistic system then learn to create (or adapt) holistic systems that tie everything together in some cohesive and coherent way.

Having said this, a holistic system isn't a foolproof plan for winning. It might fail badly in certain contexts. However, once you have mastered one system you can "train" in various contexts and learn and adapt and incorporate new things based on your experience.

Also depending on what your fighting/creating depends on what kinds of strategies/tactics/weapons you apply to the situation.

What I have seen is if you don't have a guiding philosophy for adapting and changing things then you can actually create situations where your strategies and tactics end up fighting themselves.

Over the next few blogs I'll try and flesh out some of what that all means to me and how these categories of tools come together and get applied to create various tactics.

Mintshot

I logged in and had a look at this tonight.... I pretty much thought this was going to be crap. I actually found it strangely addictive and I ended up winning a $125 Atlas :-)

www.mintshot.co.nz

Theres a bunch of stuff to be won on there.... you can either bid on them with "mintshot" dollars or you pay to play a game and whoever has the highest score will win the prize. This is potentially a really addictive thing to do. Its kind of like playing pokies except you can have all kinds of games. Certainly gives you motivation to view the ads....which are between 15 and 30 seconds lond typically

Looking up from Blub

Thanks to Randy I have had a good few days looking up from "Blub".

So, Randy posted a comment about the soloution in J for the bowling game. I read that article a while back also. Except I looked at the J code and went "what a load of crap". And who could blame me? The code looks like crap, from http://www.xprogramming.com/xpmag/dbcBowlingVector.htm , heres the code :-

framex =: 10 {. 0 {~^:a:~ _1 _1 ,~ i.@# >:@:+ 10&~:
scoreifframe =: 3 +^:(9<])`+/@|.\ ,&0 gamescore =: [: +/ framex { scoreifframe why waste your time with anything that looks like that? Well, as it happens, I think its a case of being a Blub programmer and running into "The Blub Paradox" as coined by Paul Graham and written about here http://www.paulgraham.com/avg.html

Basically, when you see a language which is more powerful than the ones you know, you're not going to immediately recognise it.

Anyways, having got Randys comment on my blog I thought I should be a bit thorough and have a look at this J stuff. I winced at the cryptic nature of the code. But even if it was cryptic, the quicksort on wikipedia in J code did impress me as its a single line of code....

quicksort=: (($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?@#)) ^: (1<#) Which is a great example of Tacit Programming ( http://en.wikipedia.org/wiki/Tacit_programming )

and J is an example of Function Level Programming ( http://en.wikipedia.org/wiki/Function-level_programming )

and J is also a a non-Von Neumann programming language ( http://en.wikipedia.org/wiki/Von_Neumann_programming_languages )

So, anyways, I downloaded J and started to wade my way through a fantastic tutorial on J at http://www.jsoftware.com/help/learning/contents.htm

Surprisingly quickly the cryptic squiggles started to all make sense and the stuff on hooks and forks in http://www.jsoftware.com/help/learning/03.htm was really quite cool.

Anyways!

All this stuff comes back to a guy called John Backus, which most anyone who's done computer science will know, is responsible for Fortran and BNF ( a notation to define context free grammars ). He wrote a very famous paper where he basically criticises languages and their designers and tells them they are intellectually crippling the world of programming. Pretty much anything in the C C++ Java C# strain of languages is crap. Or at least a crippled way of writing programs.

Anyways, the paper is http://www.stanford.edu/class/cs242/readings/backus.pdf and its from 1977. It is a very good read. Except! I have read this before, really early on in my education. I remember the idea of getting around the von-neumann bottle was pretty cool but I barely paid any attention to it because it meant very little to me. There were more practical things to be doing like trying to write C and hack VGA X mode code.

Having said all that, I'm not sure if J is really *hugely* more powerful than other programming ideas however it provides quite a unique way of thinking about programming. That in itself is very good.

Wait Wait.... Another Version of TDD F# Bowling Game

No sooner I post I reflect on the code again and see that there's some hangovers from my orginal mucking around

let score_bowls bowls =

    let rec score_bowls' frame l  =

        let nextframe = score_bowls' (frame+1)

        match l with

        | _ when frame = 11 -> 0

        | [10;s] -> 10 + s + s

        | 10 :: s :: n :: tail -> 10 + s + n + nextframe (s :: n :: tail ) 

        | f :: s :: n :: tail -> f + s + (if((f+s)=10) then n else 0) + nextframe (n :: tail)

        | _ -> List.fold_right (fun x y -> x + y) l 0

    score_bowls' 1 bowls

New F# Bowling game

After a bit of feedback from a number of sources and addressing some of my concerns with the duplication

let rec score_bowls bowls =

let rec score_bowls' frame l =

let sum b = (List.fold_right (fun x y -> x + y) b 0)

let nextframe = score_bowls' (frame+1)

match l with

| _ when frame = 10 -> sum l

| [10;s] -> 10 + s + s

| 10 :: s :: n :: tail -> 10 + s + n + nextframe (s :: n :: tail )

| f :: s :: n :: tail -> f + s + (if((f+s)=10) then n else 0) + nextframe (n :: tail)

| _ -> sum l

score_bowls' 1 bowls

TDD and F#

I've been playing around with F# a bit more lately since its been announed that its going to be a first class language in .NET.

The following code is some TDD'd code that does classic Bowling game TDD example. Interestingly it came out to be 10 lines of code, which is much shorter than equivilent C# / C++ / Java implementations. However I'm not entirely sure its super readable. It was super writable. It was very easy to add in new cases as the code progressed. I'm also not sure how much more I could improve this as I'm not a F# whizz. This peice of code makes use of F#s pattern matching abilities (not regex pattern patching). However there are so many other toys in the language to play with. I think async will be the next thing I have a play with.

The F# community is pretty small at the moment, it will be interesting to see how people exploit the language as it becomes more main stream. I also posted this code over at the hubFS .

#light

open System

open NUnit.Framework

let rec score_bowls bowls =

let rec score_bowls' frame l =

match l with

| _ when frame = 10 -> (List.fold_right (fun x y -> x + y) l 0)

| [] -> 0

| [f] -> f

| [f;s] -> f + s

| f :: s :: n :: tail when f = 10 -> 10 + s + n + score_bowls' (frame+1) ( s :: n :: tail )

| f :: s :: n :: tail when (f + s) = 10 -> 10 + n + score_bowls' (frame+1) (n :: tail)

| f :: s :: n :: tail -> f + s + score_bowls' (frame+1) (n :: tail)

score_bowls' 1 bowls

[]

type BowlingTestCases = class

new() = {}

[]

member x.SimpleScoring() = Assert.AreEqual(6, score_bowls [1;2;3] )

[]

member x.ScoreSpare() = Assert.AreEqual(12, score_bowls [2;8;1] )

[]

member x.ScoreStrike() = Assert.AreEqual(16, score_bowls [10;1;2] )

[]

member x.ScorePerfectGame() = Assert.AreEqual( 300, score_bowls [for i in 1..12 -> 10] )

[]

member x.SpareLastFrame() = Assert.AreEqual( 11, score_bowls ([for i in 1..18 -> 0] @ [2;8;1]) )

[]

member x.StrikeLastFrame() = Assert.AreEqual( 21, score_bowls ([for i in 1..18 -> 0] @ [10;10;1]) )

end

What are your skills?

Just want to vent.....

When a cook applies for a job do they list their skills as....

Pots
Frying Pans
Whisks
Chicken
Tomatoes
Spring Onions


Because many (not all) software developers seem to love to list their skills as :-

Visual Studio C#
Windows XP
Linux
PHP
ASP.NET
XML

Which leads me to believe they have no skills at all.

Waterfall Programmer

A Programmer who writes bunches and bunches of code. Compiles. Debugs and Debugs.

Having interviewed quite a few people over the last few years, this seems to be relatively common and it's very very painful to watch. This is a pattern that can turn really smart people into really bad programmers. In fact, its quite possible that the smarter you are the worse waterfall programming can bite you in the butt. The problem comes with the "unchecked" assumptions you build into the code. The more complex / cleverer your idea of how to solve a problem where you don't validate your assumptions the harder it gets to undo it later (both emotionally and technically)

To Post or not to post that is the question

Lately I've written a lot of blog posts but haven't actually published them.

Mostly they are posts with a key "idea" and then I've built up some discussion around that idea, however I find that I really want to write comprehensive essays around the topic. I eventually give the post up and leave it as a draft as it turns into a mini project :-)

I'm wondering if I should still publish unfinished posts? Or is better to keep them in draft till you can present a complete idea?


My unfinished posts are :-

Product Development
Value Stream Mapping
Cross Functional Teams
Maintaining Design Options
Design Patterns - Smart soloutions for bad languages?
How to screw up your design
Technical Debt
Whats really going on? How we end up deluding ourselves

Brain Strain

Another excellent article from Paul Graham, this time on holding a program in one's head ( http://www.paulgraham.com/head.html )

This is definitely a trait I've noticed in good programmers, they keep a problem and the code in their head. The more you can stuff in your head the better off you are. The higher the liklihood you will understand the consequences of changes, etc

Paul gives a number of points to help with keeping things in your head....

Avoid Distractions

I think this is really important. The consequence of this is, if you start doing something else when you get a break in your flow ( a long build ) such as IM / Web / Email it will start blanking out the problem / program that's in your head.

This can be a problem with pair programming at times also, sometimes the pairing can interfere with getting a problem / program into both your heads. If two people get into the same headsapce however, it can be really powerful.

Use succinct languages

succinct language and code! Building up good abstractions is very useful, if you you have good abstractions it can be very easy to express a soloution to a problem in minimal amount of code.

Having a language where you don't have to write a lot of crap to express an idea is of course very useful as well, but often the choice of language is not an option.

though I'll plug Lua once again for any C/C++ programmers out there

Good Read

good read... especially for C#ers :)

http://lucacardelli.name/Slides/2007-08-02%20An%20Accidental%20Simula%20User%20(ECOOP%20Prize).pdf

VS2008 Bad User Experience (and 2005...2003....)

You can't resize this screen. Looking at your keyboard binding you can see 3 and 3 quaters of your availble commands to bind to. Theres about 100 of them..... I'm constantly going in there to bind stuff and it always seems clumsy. It would be great if it would also help by showing "easy" key combos that haven't been bound to anything rather than having to take pot luck by experimenting with combos till I find one I like. eg, if I held down ALT it would show the combos available or SHIFT-ALT etc....

Train wreck Management

Great article by Mary Poppendieck

http://www.poppendieck.com/blame.htm


There seems to be a whole mix of management styles out there these days, it's interesting how many people are using quite old management styles and hold to quite old management value systems.

Screw IT

We started using Screwturn Wiki at work recently. It's a reasonably nice .net 2.0 Wiki. It has a nice simple plugin architecture which basically allows you to customise most things.

The only thing that bugs me is that it's not using unit tests and it really shows in the core code. Ah well... easy enough to TDD plugins for it though.

I've been thinking about writing a plugin that allows you to write lua/ironruby/ironpython plugins by simply writing code into wiki pages. This would make really really easy to write extensions to the Wikimarkup language. Though it might kill the performance of the Wiki.....

Seeing is Believing

So coming back to the "Have a Look" post...

The interesting thing about the flipping images and not being able to see the change without careful examination of the image is...

The brain creates a vivid crystal clear picture of what you are seeing. Yet your eyes can only see a small area in focus. The brain relys on the eyes ability to rapid move and focus on things to create the illusion of crystal clearness.

Seeing changes comes from the peripheral vision. The part of the eye that dosn't see the world all focused.

The flipping of images in the java app flips the images with an intermediate gray image (colour -> grey -> colour) pretty much obliterates the peripheral visions ability to notice the change. So to find the changes you have to use your "in focus" vision and interpret the image and analyse the image till finally you look at the right spot. Once you find the right spot its easy to see the change! In fact its obvious! If you show the changing images to another person it seems embarrassingly obvious whats changing, yet they too will struggle till they work out whats changing.

So how's this useful? In software UIs if you are designing something that's animated and changing and you know its animated and changing it can be very obvious to you what is changing. However, for someone who doesn't know what is changing you are relying on their peripheral vision to pick up on those changes. If there is too much noise then someone won't pick up on that change. Yet it will seem obvious to the designer what is changing. Sometimes the obvious is not obvious.

Oddly enough this issue cropped up at work where we were creating an animation of many fruit moving down a machine and getting tipped at various locations down a machine. A co worker and I were having a discussion about whether some of the animation changes were obvious or not. The person who created the animation felt it was "obvious", where as I felt that some of the changes got lost in the noise.

The lesson of the story is to test your designs with people who aren't the designers.

And the moral of the story is the obvious isn't obvious. It's embarrassing how often I forget this when I try to explain what seems "obvious" to me.

Thuderbirds are go!

Before I discuss the previous post with the weird flipping images (BTW, did you right click the image to see you could view other pictures as well? even when you know somethings changings its hard to find it)

I tried Thunderbird yesterday as a replacement for outlook 2007. I have to say, its really good! Well, mostly importantly its fast and snappy where as outlook was slow and sluggish.

Thuderbird also imported all my email which was divided across many psts to try and get outlook to be snappy..... However Thunderbird deals very gracefully with the gigs of emails I have.

I also installed "Lightning" which is a Calendar plugin which integrates into thunderbird. Its looks pretty good, not quite as good as outlooks, but it does the job.

It also has Theming support, so I downloaded a theme called "Noia 2.0 eXtreme" and the whole thing looks reasonablly pretty (though not as polished as outlook)

I also had to muck around with a few options. Oddly enough Tools->Options didnt have a lot of the options I wanted, it was Tools->Account Settings that has lots of options.

Also the built in RSS feeder works much better with Screwturns RSS updates of wiki pages than Outlook.

It's only day 2, but so far so good. Quick fast email is such a joy! :)

Have a look

You'll see an image flickering.

http://www.usd.edu/psyc301/Rensink.htm

What's interesting about it?

The Joy of Copy Paste

When considering what I think the next big thing in software will be I was using the idea that a lot of software evoloution is about avoiding Copy Pasting...

The single responsibility Principle is all about creating software with nicely seperated out behaviours that you can resuse easily

We often end up with a bunch of very similar looking "for" loops in staticly typed languages that dynamic types languages avoid.

TDD / Refactoring is all about removing duplication

However there is still a ton of similar looking software whether it be the way you deal with exceptions, threading, iteration, etc etc. Copy Paste is still a useful function to replicate some of this structure!

Some of what I like about Resharper is that it has "mini" factories which help avoid Copy Pasting things like method names.

In Ruby on Rails there are Generators that basically copy paste the right things into the right places for you.

I make macros and templates and generators that automate the common stuff I do.

So what we need to do is try and put this concept on Steroids. Powerful software/coding factories. One problem with these things at the moment is that once something is generated we lose track of it and have little ability to regenerate things. So we endup with the pitfalls of Copy Pasting. Still, its hugely more productive to have these kinds of generators.

Information Design

Interaction Design often takes the spotlight when we consider User Experience, However, theres a bunch of interesting goings on in the world of information Design.

Its worth spending some time getting to grips with Information design as we often add interaction design because we don't have good ways of presenting information to users.

One of the better articles on this is Magic Ink

Another interesting web page is here

With technologies like WPF we also get to add animation to all this! The skillsets we need to make software products is going to get really interesting.

The Next Big Thing in Software Development

After the post from William I was reflecting on the buzz of the early days in the Extreme Programming group. There was lots of stuff going on, lots of ideas going around, lots of people trying things, and a bunch of those people are now authors of some well respected books, blogs, and tools.

These days much of the XP user group is around the subtleties of XP and teaching newbies the basics. Many of the ideas, tools and techniques are reasonably mature now.

The two other big things that were going on at the same time was a surge in dynamic and functional languages and techniques and also Usability / User Experience (Ux). These ideas haven't fully gone mainstream but they are picking up popularity at a rapid rate.

It's been fun riding the edge of some of these things.

The question is, what's next?

I think the next big thing in the software world is going to be software factories. They are not a new idea, in fact I remember hearing about some of the ideas that make up software factories back in the 90s.

The thing is, software factories at the moment seem a bit kludgy. They aren't easy to create and they aren't easy to use. I think the power in them is when it's easy to create your own and wield them with the power of things like Resharper. I think a bunch of software technologies are slowly aligning to make these things a lot easier.

I think once we have practical software factories that are easy to create and use the level of productivity of those using them is going to sky rocket.

IronRuby Code

the IronRuby source code is available here http://iunknown.typepad.com/IronRuby-Pre-Alpha1.zip

Just had a quick look....

Mostly looks ok. However, I don't like their approach to unit testing. In fact what it has is really Acceptance Tests. It shows in some of the complicated methods they have ended up with. Lots of odd bits of code all around actually... Still! good to see some progresss :-)

Requirements Capture?

A great quote from William Pietri about XP's perspective on Requirements when reflecting on the word "Capture" (from the XP user list)

"but as far as requirements go, we're more naturalists than hunters. We like to observe our requirements roaming free in their natural habitat, rather than stuffing and mounting them for our trophy room."

Burst of Air

This is a bit off topic....but might be vaguely useful to someone if they manage to find it.

I recently bought Chessmaster 10th Edition.   So I install it onto my Compaq nw8240.  Its a reasonably beasty computer and should handle this fine.   I go into some of the tutorial stuff, all seems fine.  Then I starting playing in Training mode and something very curious happens.  The game starts slowing down.  Then freezes.  Then I have to shut the computer down with a power off.  The computer seems to be running really hot.  So I try it again, same deal. 

I leave it a few days and just do the "Academy" training stuff and the puzzles and things.  But actually playing a game of chess seems to cause it to die.   I figure for $25 it still is a pretty good deal, but I really would like to play chess!   I have a copy of Pawn2 which is ok, but fairly limited.    

So I ponder whether my computer getting really hot because the game is using a lot of CPU and the whole thing falling over is perhaps due to the inside getting too dusty.

So I hunt down some "Air Burst"   (which I couldn't get at Dick Smiths, out of stock in two stores, but a Mitre 10 had truck loads of the stuff).   I  spray it into various vent on the computer, a bunch of dust comes out,

*spray* *spray* *spray*  This is quite fun!

Get some tweezers and extract a few dust balls that just can't quite make it out the vents.  Then I turn my computer on....run up chessmaster, and Ta Da! I can play chess.   It runs really well.  Great game!

Most surprised that actually made a difference!

I'm also noticing the fan doesn't turn on nearly as much when I'm using it now either...    So something to keep in the back of your mind if your laptop seems to be running slightly hotter than usual!

Refactoring your Editing with Resharper 3.0

Jetbrains have release a new version of Resharper.

 

This is simply a fantastic tool!  Though, if you are new to resharper it can be hard to see why its so good.   It's not until you see a Resharper Jedi  at work do you really understand why people rave about it.

 

The real trick to it is learning / customizing the keyboard bindings and then letting them become second nature.

The second major trick is to go through all of the resharper goodies and all  the options and customize the settings.  Make your own live templates, your own file templates, bind it all to keys.  

Now you can refactor your editing.  Any time you duplicate any kind of action / typing, then chances are you can automate it with resharper.  Never type a for loop again, learn the magic of Alt-Ins

 

It also helps with XML and XAML.   Nice for WPF type development, though there's a heck of a lot more Resharper could do for XAML.

WPF Goodness

I've been actively playing with WPF and we are currently converting a "machine simulation"  ( www.compacsort.com )  over to WPF.  I really like it!  It's not perfect, but its definitely a big step up from winforms.

I was browsing through...

http://www.orbifold.net/default/?p=713     (need a free ribbon like toolbar?) and he mentioned only around a 1000 people had downloaded kevins bag of tricks and that he was seriously worried about the future of WPF. 

 

Well, I was one of those people to download it a while ago and was impressed with what you could do!  so if you haven't already (only 1500 odd people at the time of this post), download from http://wpf.netfx3.com/files/folders/10297/download.aspx

 

If anyone else has links to good wpf resources, can you point me in the right direction? :-)

Resuming MSDN subscription downloads

If you quit the Microsoft File Transfer Manager in the middle of it downloading all your goodies from MSDN. Before you do so.... Go to the Options in the transfer manager and select "place application shortcut on the desktop".

Or, if you forget to do that, look in your \WINDOWS\Downloaded Program Files\TransferMgr.exe

Which won't show up in a search or in explorer by default, so simply run it from the command line or your run box.

Mixing WPF into WinForms

Just came across this today.  I was just seeing how easy it is to mix winforms and wpf (completely simple).  The only issues was it came up and said it didn't know what InitializeComponent() was.     This is because it wasn't compiling the XAML.   So...you need  :-

<Import Project="$(MSBuildBinPath)\Microsoft.WinFX.targets" />

in the project file (near the other similar looking import)

Explainable Design

I was reading a blog post called "Four Factors of Agile UX" and one of the "factors" is

"The ability to explain a design efficiently is vital to the success of a project".

I think this is a fantastically good design principle. Anything you design should be explainable in a reasonably straightforward way.

One of the tell tale signs of smelly design is when you do try and explain it and you start doing.... "And then the Widget puts the......oh...hmmm....hang on, that's a bit strange, hmmm, wonder what that's doing?....hmmm....". Suddenly things are not quite as you thought they were. Complexity is pretty sneaky and often sneaks into designs when your not paying attention.

It is important that its explainable in words you say out loud and not inside your head. So you can't cheat and look at a design and say to yourself "yep! makes sense to me! I could explain it!". Of course the best way to do this is to discuss your designs with someone else.

Gavin is blogging

One of my coworkers, Gavin Lambert, has started blogging at http://lambert.geek.nz/

One of the great things about Gavin is he likes to get inside the guts of things and consequently digs up some real nuggets of information.

AlligatorEggs

from the maker of Magic Ink.... http://worrydream.com/MagicInk/

http://worrydream.com/AlligatorEggs/

This is a cool little game with cutout alligators and eggs that demonstrates lambda calculus!

I Like Microsoft today :-)

I've been watching a bunch of blogs about the Mix event by Microsoft ( couple of local blogs http://www.syringe.net.nz/ and http://turtle.net.nz/blog/ ).

There's tons of stuff being announced that just cool.

Extensions to the CLR for Dynamic languages, IronRuby, Silverlight, Expression....and more!

This stuff is all great, and pretty much what I've been expecting from MS, though I didnt know the Dynamic Language stuff was so close! The other cool thing in Microsoft is F# but there are no major announcment around this, but I think its an important development.

Anyways, all up, it means anyone developing on a .NET platform is going to have some really awesome tools!!

Well done Microsoft.

XAML

I'm in the process of playing around with WPF. XAML is the markup language for creating WPF based UI. But, its actually more generally useful than that.

It can be used for any objects. Which makes its reasonably good for any kind of object creation / dependency injection / configuration.

I haven't had a chance to play with this much yet, I'm still on the steep part of the learning curve for WPF and the underlying architecture. I'm looking at how MVP/MVC and TDD fit in with it all.

As little Unit Testing as possible

When you first start learning TDD. It's all about creating unit tests. However, very quickly you learn its actually all about making as few unit tests as possible.

One of the traps people can fall into when doing TDD is testing lots and lots and lots of stuff. This means when you change your design you break lots of tests.

Ideally what you want is tests that test your intention. Tests that show what the code has to achieve. It doesn't matter too much how the code achieves it, and you don't really want to test how it achieves it. That way you can vary how it is implemented without breaking lots of tests. ie, Encapsulation.

Of course there are going to be plenty of things that may break tests as they slice through a layer of encapsulation.

However, if you test things pretending that the thing will magically do what you want without worrying about how, then it can be a heck of a lot easier to get good tests. When you test with a particular implementation in mind, you often get very concrete tests that fall over as soon as you try changing things.

Architecture Camp Finished! + My Powerpoint presentation

Architecture Camp was really good! It was great to see people really interested in the content presented and activelly discussing ideas.

Some interesting things to me...

Quite a lot of people were using mindmaps to take notes, great stuff!

There was quite an agile theme to many of the talks.

Martin Fowler is quoted a lot!

Integration / Deployment Architectures are hot topics.

No one had any idea where one would go to buy yellow camo

---

Heres my Slides from my talk. Most happy to answer any questions or discuss any ideas related to them!

Pearls Before Breakfast

There's a great article in the Washington post called Pearls Before Breakfast. It's about how a top classical violinist in America (just voted Americas top classical musician) went to the Washington DC Metro and started busking.

Most people walked on by.

What does that mean? The article explores some of the possibilities. But, there's a couple of things I take from it, quite often things of beauty (music, art, design) need to be presented within a context for you to appreciate it. Relating this to software design, this means unless we stop and look at good design and appreciate it for what it is, we are most likely to pass it by never realising it was good design.

The next point to take away is also really interesting. It's also really odd, because I was talking about exactly this with a co-worker yesterday! That is Immanuel Kant (philosopher) said that beauty cannot be truly experienced unless we have a sense or morality. or, Without a sense of whats right and whats wrong, we can't appreciate beauty. Appreciating beauty is not the same as liking something either. I think theres an element of objectiveness to beauty and whether we like something or not tends to be quite subjective. Having said that, Kant didn't quite say this at all, he painted a fuzzier picture of how beauty and morality tend to interact. Kant's most famous moral idea is "The Categorical Imperative". This a set of 3 basic "rules", however, most of interesting discussion is based around the consequences of those rules and what they mean.... Anyways! How does this relate to software development? It means we really need to spend some time understanding what good code is and what bad code is. The tricky thing is that what's good and bad is not carved into a rock anywhere. However once we start developing a sense for what good and bad is we then tend to recognise beautiful designs and why they are beautiful. With a bit of luck we can hone our sense of "Code Morality" so finely that we won't walk by a Masterpiece out of context.

Architecture Camp registrations now open!

If you haven't heard already, you can register for Architecture Camp. I'll be talking about Evolving Architectures. I'll be waffling about thinking tools, refactoring, patterns and ways to try and create good designs!

Also, I realise I suck at blog posts! my last post didnt mention that I got the link to TED from Allen Holub, and secondly, I didn't even put the link in the post!

so here it is....

http://www.ted.com/tedtalks/

TED - Technology Entertainment Design

Continuing my pasting interesting links rather than formulating my thoughts into blog posts.....

But, this time I will make a bit more effort to ADD value by hyping the link and explaining why its worth having a look at!

So, I received a newsletter email from Allen Holub. Allen has some great ideas on software design and at the very least all software developers should read his article on why setters and getters are evil. (also continuing from the last post concerning the social psychology that software developers tend to bump into, he has a good link to "Unskilled and unaware of it". Which also feeds into a great link I got from 37signals which is Judo quotes which are applicable to any pursuit really).

Anyways.... So TED... This is a conference in California where they get a bunch of people who have interesting ideas in the areas of technology entertainment and design. I downloaded several them earlier today and watched them. They are good! The one I found especially interesting is the one from Neil Gershenfeld. He talks about whats beyond the digital revolution. His talk focuses on computability entering the physical world. Things that can make themselves. Programming Biology. Creating and building real things customised to the individual. He talks about Fab Labs all around the world where kids / adults are creating devices and technology that solve local problems. He makes references how 3 MIT students are doing research papers on designs 8 year olds have come up with from these labs. Really quite interesting stuff! It also is quite related to a post Rod recently made.

What I'd like to know is what we are doing in New Zealand with these ideas... with our so called #8 wire innovation we should be eating these ideas alive!

The other thing I like about these talks is that the idealistic "feel" about uniting humanity through technology and understanding comes through quite well. Some talks deal with the problems of technology and the modern world and some paint a picture of a future based on these emerging ideas.

A Group Is Its Own Worst Enemy

I came across this http://shirky.com/writings/group_enemy.html on the lua mailing list. Makes for a good read!

Nothing to do with designing code though....

Architecture Camp 2007 - Auckland April 14-15th

http://www.base4.net/Blog.aspx?ID=347

Beautiful Code

This is a note to myself to get the book talked about :-

http://pyre.third-bit.com/blog/archives/863.html

Theres a link to amazon but its not released....

http://www.amazon.com/Beautiful-Code-Leading-Programmers-Explain/dp/0596510047

Design Culture

I've been pondering over the last few months the notion of a "Design Culture" as the underpinning to software development (and more generally, product development).

This idea embraces design in a philosophical, social, and practical sense. The process you use, the techniques you use, the team, the values, etc all feed into a "Design Culture"

This means your software, your selling, your marketing, your customer service, your environment, etc all are done within a "Design Culture".

The reason I want to try and capture this idea is so that I can explain what the motivation is to do something a particular way. For instance, refactoring. It is one of the key ideas of TDD. But often it is not done "extremely" enough. Simple duplication gets removed, but really striving to separate concepts and name concepts with good names is neglected. The motivation to make a simpler design can be missing, especially once you have code that works. But this is only one tiny tiny example of a what I would imagine one *kind* of "Design Culture" would entail.

I'm not quite sure how to define it, I think I'm trying to find something beyond "You should strive for simplicity" etc. I think I want to know what makes people happy about the things they have created. Which sounds a bit wishy washy but I think it gets at the heart of what really motivates people to create good designs.

Which if we look at the idea of simplicity and my experience of creating simple designs, I really enjoy the intellectual challenge of taking something complex and finding the simple building blocks that create that complexity.

Then applying that back into the "Design Culture" we would have some notion of intellectual challenge. Which in turn has implications about techniques and skills for comprehending problems, expressing solutions, trying ideas, etc etc.

Katana

Random non software related post!

For years and years I've had a practice katana (not a sharp blade) since it's generally far better for keeping your body parts attached to the proper places.

However, I just bought a hand forged katana from http://www.gengswords.co.nz/



I'm also looking at getting a second one from the same place (you can never have too many swords!)

Interactionary

This looks fun :) We need 1 or 2 people to make a team, contact me if you're interested :)

---------------------------------
The first UPA Auckland event this year is going to be an Interactionary on March 6th.

Interactionary session

Imagine a cross between Theatre Sports and NZ Idol meets User Centred Design.

Want to play?

Form a team of 3-4 people before the night and RSVP your team name, team captain’s contact details and team members’ names to auckland@upa.org.nz before February 28th.
Take the challenge of solving a design problem revealed on the night and design a solution in front of your peers in just ten minutes and scored by 3 guest judges.

You will be scored on the following criteria (although scoring isn’t the primary goal, having fun is):

* Teamwork: * Process: * Final Design: * User focus:

You wont know the design problem until the night. Depending on the number of teams, heats will determine 2 highest scroring finalist teams who then play off in the final design problem.

If you would like to be part of the interactionary but don’t have a team, email us and we’ll match you up.

* RSVP: Please RSVP to auckland@upa.org.nz by 5pm Monday 5th March (for observers, by 28th of Feb for teams)
* Time: 6pm onwards for drinks and nibbles.
* Talks start at 6.30pm. Finishes at approximately 8pm
* Cost: $10 cash at the door. Please bring correct change.
* Location: Bank of New Zealand, 3rd floor, 125 Queen Street, Auckland
* Late entry: Call Mark McLay on 029 222 00 16 if you have difficulty getting in or arrive after 6.30pm

Usability Professionals Association of New Zealand, Auckland cluster Auckland’s UPA meetings are usually held on the last Tuesday of each month.

Lean Software Development

Recently we had Mary Poppendieck give a talk at Agile Auckland

Mary is a great presenter and she really knows her stuff! I orginally met her at OOPSLA in 2004 where she was giving talks and promoting her book Lean Software Development.

Anyone interseted in Agile ideas should have a look at her stuff. Especially if you don't buy into "All" of agile and are more interested in customising "agile ideas" to your own enviroment.

Anyways, the slides for her presentation she gave can be found at http://www.agileauckland.com/Beyond_Agile_Auckland_2007.pdf

Refuctoring

In my continued effort not to have to think too much about my blog posts, the following link was posted to the XP list by Michael Feathers.

http://waterfall2006.com/Refuctoring.pdf

Conditionals

gotta love this paper from 1960. 47 years ago, a new language concept of conditionals for a new language called "lisp"However, it still shows an elegant way of solving certain kinds of problems that a lot of languages still don't have

Million Times faster Regular Expression matching

This is an interesting article on the state of Regular Expression matching in a lot of "contemporary" languages.

Multithreading and Lua

There's a cool quote in the paper The Evoloution of Lua (Section 5.4) that says...

"Second, and more important, we did
not (and still do not) believe in the standard multithreading model,
which is preemptive concurrency with shared memory: we still
think that no one can write correct programs in a language where
‘a=a+1’ is not deterministic."

It certainly makes it blimmin difficult to write correct software.

For those who don't know Lua, its a great scripting language that's a good balance between scheme/lisp/ruby etc. Its easy to embed into an application (in fact a number of games use it), its fast, it's simple, nice syntax, and powerful. www.lua.org . One of the interesting thing about Lua is that it doesn't have native support for OO (in the way C++ / Java / C# / Ruby) do. But because of its meta programming approach you can add OO constructs. You can define what a "class" is and how "inheritance" works. Which is more lisp like. This approach is quite good, as it means it's a "multi paradigm" type language, where you can program "functional" or "OO" or mix it all up, create DSLs, or whatever. The disadvantage is that you can end up with a bunch of different approaches that don't mix well.

I'm it

I've been tagged by Alex to tell everyone 5 things about myself that people probablly don't know. It's been interesting reading all sorts of peoples blogs on this. So I guess I'll join in :-)

1. I did martial arts for 16 years, Karate and Bujinkan (Ninjutsu)
2. I love studying philosophy, psychology, and religion. I'm interested in peoples belief systems, my beliefs, and why we have the beliefs we do. I am intrigued in how powerful ideas can be in changing peoples experience of life.
3. I lived in Italy during my teens as my father was doing research in Turin. I remember we were living in a place with 14th and 17th century furniture and "ladies of the night" patrolled directly below my bedroom window (we were on the second floor)
4. I suffer from insomnia to the mystery of myself and doctors.
5. I've never been to a concert ( rock, pop, classical or otherwise), this surprises many people, I have no idea why I've never been to one, it's not because I dont like music, oddly enough it's never occured to me to go, and there's been lots of times where I almost ended up going to one with friends but for some reason it never happened.

As for tagging other people, I'm going to make a dead end :-)

Design Rules

There are no design rules.

We create software by creating levels of indirection. Design is about having effective ways of manipulating these levels of indirection.

There's no one way of doing this. There are lots of ideas on how to do this. Some ideas are super effective for creating designs that solve certain types of problems but this dosn't mean they will always be the most effective

I think it's therefore a good thinking tool to not categorise oneself as a particular kind of designer, eg "OO", "Functional", "Procedural" etc as it can limit your design choices unnecessarily. I also think categorising your design as "OO" or otherwise can also limit your design options.

This doesn't mean you apply every idea that all the other cool kids are using. Your designs should be reasonably coherent and understandable and not a big messy mish-mash of ideas. Though it does get tricky when you want to introduce new ideas and techniques into an existing system.

So what's my point?

There are no rules. However, coherent and understandable systems tend to have "pseudo" rules. The trick is to not mistake pseudo rules as fundamental rules.

Simple Design

This is such a common idea in any kind of activity that requires any kind of design.

There’s the many time quoted "Make everything as simple as possible, but not simpler." by Albert Einstein.

And at first glance this all makes perfect sense and seems quite wise. The problem is that it doesn’t make for a particularly good thinking tool. It would be great if you could look at a piece of software and go, "ok, let’s make this as simple as possible". This often doesn’t help! It can help for getting rid of some obvious crud, but often this keeps the design the same and simply cleans it up. Finding the simplest possible design out of an unbounded set of designs is a lot more complicated than it first seems.

It can be hard enough generating alternative design ideas, often ideas are constrained by various assumptions, the language your working with, the technology your working with, what you've worked on previously, you knowledge of patterns of design etc etc. How would you feel confident that you found the simplest design?

The more I look into design and see all kinds of alternative ways to design things the more I'm not sure what the exact nature of simple design looks like. Of course there's lots of ideas on how to simplify designs, and there's some great frameworks that make things that were hard to do a lot simpler. But...

I think that there is no absolute simple design. I don’t think it’s even definable given a bunch of constraints (eg, context, purpose, etc)

Not that I think anyone thinks there is an absolute but it is worth keeping in mind that simple design is more about having a "quality" of simplicity rather than being simple or not.

Pretending to have written code

This technique is all about writing code based on code you pretend you have already written. TDD uses of this technique to great effect. The idea is you write a test based on code that doesn't exist yet. So, you invent code that you need in order to express the test. Then, once you have the test, you create the real code for the stuff you pretended to have and make it do what it needs to in order to make the test pass.

Great stuff.

However, the idea of pretending that code exists extends beyond simply expressing a test. It also works well for writing the code itself. Write the body of a method assuming that the objects, methods and variables you need are already there. This allows you to play with solving the problem without worrying about having the infrastructure to actually make the code work. This is powerful.

Some of the problems you see when you don't do this....

You start solving a problem, and you figure you need a method in order to solve the problem, so you go build the method, then you go back and try to complete the problem only to find you didn't really need that method, you actually need something quite different. Basically, when your solving something at the specification perspective write the code imagining you have all the things at the implementation perspective.

You ponder a problem and start putting in a bunch of variables that you think you need in order to solve the problem. This can cause all sorts of grief. Firstly, you tend to build infrastructure that you don't necessarily need, and secondly, and probably the worst effect, you can start constraining yourself about how to solve a problem in terms of the variables you have created. This can be massively limiting and can mislead you for a long time especially if you are resistant to throwing code out. This is one of the more common mistakes I have witnessed.

There is an idea in lean manufacturing that you delay decisions to the last possible moment. Or flipping that around, you leave your options open as long as possible. You want to do this in code also, if you make your mind up too early about something it can constrain your thinking and close out alternative solutions before you need to.

By pretending you can express your thoughts faster which tends to give you quicker feedback about whether you understand an idea or there are gaps in your knowledge. ie, quicker learning. As you learn you conceptulise what you need from the implementation perspective without actually writing it till you have conceptually solved enough of the problem that you need the implementation in order to pass a test.

The counter argument I have heard for not doing this is "It's not the way I think", but I think this is a hangover from when you first start programming. When you first start programming in a language your not entirely sure what's possible and what's not. If you write a "pretend method" your often unsure whether you can build the infrastructure or not. example "I wonder if I can hold arrays of strings?" So you investigate whether you can build the infrastructure you think you need. However, once you get proficient at a language/coding you generally know what's possible and what's not. You know what concepts you can express. Sometimes you don't, so its worth going off and investigating. But in general you know.

The constraint to this idea is that you don't want to pretend for very long. You want to work in reasonably tight cycles of writing tests, writing code. And by no means is this a "rule" it's just a thinking tool that can help you write good code faster. It's possible that pretending can constrain your thinking also, so it's good to have other thinking tools you can use too.

It's a matter of perspective

One very useful thinking tool I've used a lot when evaluating code is the concept of "Levels of Perspective". I haven't seen too many references to this concept, I orginally saw it as a simple side bar in UML distilled by Martin Fowler. There's a few people who have picked up on this idea and I find it really good. I have another blog post sitting in draft where I was going to flipantly make reference to this idea but I thought I should blog on it for those who may not of come across it. It's a fantastically useful tool because I find in a lot of peoples code these perspectives get mixed up willy nilly and its a great tool to work out how to start refactoring a tangled mess back to sensibility. When pointing out this idea in relation to code I see people going "Ah!". (hmmm, wonder if I've praised this concept enough?)

The levels of perspective are :-

Conceptual
Specification
Implementation

The conceptual perspective is to do with classes of objects in your design. What responsibility each object has and hence where methods should live. Common mistakes you can make when you get this wrong is methods on the wrong object hence some objects knowing too much about other objects. Names of classes and methods dont make too much sense when trying to explain your design. Abstract and concrete concepts are mixed together ( I'll do a blog post on this one a few posts down the track because this is one of the main causes of bad design that I've seen, but, theres a few other ideas I want to chuck out there first).

The specification perspective is the particular steps you need to take in order to fufill a responsibility. eg a Move responsibility would require a "Remove From Source" and "Add to Target"

Implementation is the actual code that achieves a particular step of the specification.

A common thing I see is that specification and implementation stuff get mixed together. Often this is done innocently at the beginning but can start making the code confusing as it evolves. Simply separating out these two perspectives can make for much simpler methods.

Once you have specification stuff separated out it then gets simpler to pull this out as an interface then you can vary the implementation by simply providing different objects that implement this interface which then allows for any kind of dependency injection (blog post to follow later....). If your using a language which has duck typing then this is even easier. The specification also helps with talking abstractly about how to solve a problem which then helps you rationalise about the closure (blog to follow later...) of the abstractions you have made. What I mean by this is that you create a language where you can fully talk about the concept your working with.

For example if you are working with a stack, the language "push", "pop", "top", "empty" provides a language to play with stacks. If you forgot to put the "empty" method in then you wouldn't have closure and it would get harder to express how you want to manipulate a stack.

So developing a good specification perspective helps you rationalise about your objects, it helps clear up abstractions, which provides good language that helps you write more understandable code.

All of this is nicely summed up with the "Open Closed Principle (OCP)" (bog to follow later...). A fundamental idea of OO deisgn but OCP is almost too simple of an idea that its often hard to appreciate the subtle influences it can have on your design. That's why I think you need a bunch of thinking tools, like levels of perspective, to help you reflect on how all these thinking tools work.

There's a lot more that could be said about levels of perspective that I could be here forever! However this idea overlaps with many other ideas and I'll refer back to this idea in other blog posts which will hopefully shed more light on all of this.

Don't burn your bridges

Just a followup on my last post and reflecting on Alexs blog about when to kill code.

There's a concept of scope that needs to be taken into account. The scope that I had in mind for my previous post is the day to day code your building. If your about to build a bridge and you dig a hole in the wrong place for the foundation. Back out of it! Don't carry on and "just make the bridge fit".

However, as in Alexs case, sometimes the whole "bridge" is in question once its build. There's fundamental changes you want to make. This can be a lot harder. There's a number of options.

1. Modify the existing bridge in a disciplined and engineered way. This often has a lot of challenges and you often have to work within some limiting constraints. But it can be a good option. It really depends on how fundamentally different you need the bridge to be.

2. Build a new bridge near the old bridge that meets all your needs, provide transitioning roads from the old bridge to the new bridge. But this also has problems, the transitioning from the old bridge to the new bridge may be quite difficult.

3. Build another bridge in another location with no transitions and just hope traffic will change over to using this bridge.

4. Burn the old bridge down and start again. This is probably the worst option, during this time no one can cross the bridge, you effectively destroy a bunch of value and take ages to get the value back.

Everything has pros and cons, there's no clean easy "right" answer. Software is a bit more flexible than concrete structures so we can exploit that to some degree, but there are always tradeoffs, especially when your creating platforms that other people build things on top of. However whatever option you take, in general, I don't think you should burn your bridges.

Don't throw good code after bad code

One effective technique for writing good code is chuck out code that's not working out too well. This is probablly one of the harder techniques to get to grips with. It's pretty easy to understand the idea, however, when your actually writing code and have created a bit of a mess it is easy to convince yourself to keep tinkering to get it right. Or, alternatively, you figure you can refactor your way to good code. Usually there's something in your head that tells you that the approach your taking sucks but you know you can hack it to make it work.

Don't. Cut your losses and kill the code.

The fact you realise that it sucks means you probablly understand the problem a lot better than when you first started. Thats the key thing, that's actually the hard part, writing code when you know exactly what it has to do is often reasonably trvial once your confident in a particular language.

You might salvage the unit tests, but sometimes its better to biff those out also. This gives you the chance to rethink your approach afresh.

For starters you might just comment out your code "just in case". This is especially true if the code you have generated is quite complex. Your not quite sure if you can recreate it. However this is often a big stinky code smell and most often you will find a simpler soloution when you do it again. So once you get used to backing out of code then you'll just delete it.

Separating Command and Query

Separating command and query is an idea that Betrand Meyer came up with. The general idea is that a method should either be for changing the state of an object or querying that object about its state. eg

widget.Add( 12 ); // command
x = widget.Sum(); // query

Calling sum won't change the state of widget. In fact it is referentially transparent, that is, the call to sum can be replaced with whatever the result of sum is without changing the behaviour of the software. ie

x = 12;

Which just means calling Sum has no side effects.

On the other hand, the command Add" can do whatever it likes to the object. There is no result from the add that represents the changed state of widget.

So why is this a good thing? It helps in separating your code into simple methods that are responsible for just one thing. This often simplifies code. One of the mistakes I have seen people make is that if you have some action that returns a value (mixing command and query). eg

int count = widget.Add(); // returns the number of items in widget

And you use this method in one place, everything seems fine. Sometime later you find you really need to know count somewhere else. But the only way to find out the the count is by adding something. Nuts. So you may end up storing the value of count somewhere for later retrieval but then this starts complicating another object with the details of widget, and worse, count may be wrong by the time you use it, or, even worse yet, you may end up doing a hack that Adds something to get the count then immediately removes it again. Where as what you really need to do is separate the command and query and simply ask the widget for its count whenever you need it. This is a bit of a simplified example and generally you fall into this trap when the objects and methods semantics are not so clear. In fact sometimes renaming a method can be all that's needed to show this confusion.

Of course, there are many examples you could come up with as to why you may not want to separate command and query. That's fine. As long as you know you're doing it. Most of the problems come when you don't realise your doing it. It's just one thinking tool that helps you evaluate code and potentially help you name a problem.

One nice thing you can do if you do with commands is return this/self as the result. This then allows you to do command chaining eg.

widget.Add(1).Add(2).Add(3);

For some, this whole command query thing may seem all too obvious and trivial, but I wanted to blog on it since I have seen people getting their code in a mess because they didn't make the clear distinction between command and query.