David Ing's Weblog

Some Quick Notes on Node.js

2011-03-09

Node.js is N in a series of O attempts at a Javascript server-side programming model. I’m not qualified to describe it in great detail, having just started to get to know it properly, but I wanted to share some notes on what I’ve learnt so far.

Node.js is interesting because it uses Javascript. The evangelism argument of why this is A Good Thing is that this language is ubiquitous and pretty much cockroach-like survivability odds skills-wise come what may – when your current language-du-jour is desperately out of fashion 3 weeks from now then Javascript will still always just be there looking at you a little smugly. It’s the lingua franca of all browsers and the new BASIC of the web view-source generation.

Now Javascript is a good person struggling to get over a bad personality, in that although usually all it does is the workman dull job of crawling over a DOM or trying to figure out how to open an annoying popup window, there is nothing fundamentally wrong with it as a language. In fact, it’s actually quite a pleasant thing once you get to know it. The use of continuations and how it handles closures as part of it’s event programming interaction makes it an interesting choice for asynchronous style event programming.

There is a theory that Node.js will become popular because it uses this Dr Jekyll version of its personality (he’s the good one, Farmville Fans), and that the Mr Hyde alert();alert() part is suppressed. The happy day scenario here is that once you’ve learnt Javascript then you’re all set for both client and server side programming models. One Event Model to Rule Them All. We also have the current situation of vendors falling over themselves to impress with their browser VM performance chops, in that ‘making the web work faster’ is a nice side goal of us all getting better and better Javascript run-times. The Google V8 project and its decoupled extensibility hooks have allowed Node.js to exist on the server and scream along in speeds only dreamt of in the futuristic nightmares of the IE6 team.

What worries me personally is more that I’m increasingly thinking of Javascript as more of a build target – something to be used as a intermediary language like the CIL or byte-code. Whether it’s things like CoffeeScript cleaning up the var/bracket noise syntax or Google Web Toolkit it shows that Node.js’s appeal can’t really be Javascript per se. If preprocessing is seen as some vital rouge on the cheeks of the pig, then that’s not a good argument for loving Node.js language ubiquity so far.

So if a single client / server universal language isn’t the appeal then there is the elegance of the programming model. If you haven’t already it’s worth browsing the Hello World style http example here http://nodejs.org/. The style is wonderfully fluent and the advantage is in the non-blocking nature of those function calls. An event-queue model on a single thread (yes, exactly like a browser Javascript engine) can be argued to more efficient in terms of throughput than cranking up new threads or processes. What you lose in fault protection you gain in context-switch, and there is lots to like of the underlying style that Node.js uses through its Javascript genes to make event-driven throughput applications.

So far it seems that Node.js is breaking the community ice by being used as a message in / message out scenarios, with websockets being the obvious target on the client browser. There is lots to be impressed by in how little CPU/Working Set is claimed by this event queue style and it shows a lot of applicability for other non-networking shuffling apps. It’s lean but not quite as mean as some other ‘harder’ functional programming models.

Node.js has a nice package manager already called NPM http://npmjs.org/, and with that in place is all set up to grow in lots of different directions. I can certainly imagine (and have seen a few already) MVC Rails like scenarios, Template-like Sinatra scenarios and JQuery functional client/server hook ups. The modules have a nice dependency hierarchy mapped out, and the package bundler seems to be straight-forward JSON files. The building blocks are certainly in place for growth of the framework and the libraries.

Finally, the nice thing about Node.js is that it’s not yet massive, in that it’s still emerging and growing and that the underlying framework is of a size where you can browse the API and get your head around it. Whether it’s around for the long-haul is debatable but it’s a really interesting evolution of Javascript on the server and brings a lot of practical functional style programming in a really elegant way.

Definitely a project to watch.

What Next?

2011-02-27

The recent 10 year anniversary of the Agile Manifesto is a good reason to be reflective on where software practices have come from and where they might be going. Plus the Oscar’s are on TV so I have taken refuge in my office and I’ve run out of new books to read.

Parallel Worlds

I do not think Agile software development methods have crossed over to the mainstream developer. That may seem a confusing and contentious statement, given on how much noise and words are generated in the community, but I suspect it to be true. We’re in a curious time where the two worlds of people-over-process and process-over-people seldom now need to coincide. These people do not meet each other at conferences.

I keep coming across entire offices where unit testing is considered some new ‘pointless what if’ dark art, where refactoring code is seen as a weight dragging schedules down to the abyss and business’s treat software as some hell-forsaken never-ending cost-center that needs to be continuously kept in check through arbitrary metrics. This ‘Dark Matter’ to balance the equation of industry numbers is out there. I know it’s wrong to wave assumptions around like a baby with a loaded gun, but I’d take a bet that less than 10% of software teams working today actually follow the principles behind agile.

Additionally, I think these two worlds are actually diverging rather converging, in that those who agree with the cut and thrust of using an agile process are now on a path of enthusiastically pursuing it, while those who have chose not to have more or less now decided to ignore it. Agility in the processes, the teams and the ethos you regard quality with, is heading in a direction that’s diametrically opposed to what’s considered ‘traditional’ software development. Both camps are pretty well entrenched on their respective paths, ready to disown each other’s foolish and ultimately doomed ways.

Elephants

The elephant in the room for adopting Agile processes is what to do when you reach the impasse with those running the business: Of what to do when you come down to the ideological gap between putting trust in people and delayed gratification in front of the cold and hard reality of the immediate bottom-line results and dollar revenue streams. One solution has been the ‘productization’ of the agile concept (and which excellently discussed by William Pietri here) but that just seems to leave both ends of the spectrum disappointed – we now have Scrumbuts fighting the long death-march dual-front of both Agilists and Non-Agilists with their disdain for lack of purity in a weak middle-ground of nothingness.

The underlying problem is that it seems to come down to having to completely change the culture of an existing business. This can be done internally, and often is done by heroic souls today, but like the advice of how to eat an elephant (‘one bite at a time’) after a while anyone’s going to get pretty sick of tasting just bad elephant every day. I see a lot of people who would previously tried to change an organization within now feel it’s easier to just go compete with their former organization’s business – ‘If you can’t beat em, take their lunch’. The lack of repeatability of costs and features makes it a frustrating job to try to change the mindset of a business through the necessary terms and language they need to use; that of short-term-centric revenue and expense.

It seems the future of Agile is not to change existing processes and thought, but for people to now separate software away from intransigent businesses and see it as either something they either buy or hire 3rd party specialists to go and build for them. If building software is not your core competency then perhaps embrace it entirely or treat it with the contractual distrust you probably would be more comfortable with.

It might sound a little nihilist for a ‘You can’t get there from here’ gloomy prognostication, but what I’m trying to say is that the biggest lesson of Agile software might not be to change how everyone can do better software but to make the gap between good and bad so obvious as to split into a specialization of core and non-core competencies.

Small is Beautiful

The most major difference to software development over the last 10 years for me has been the amount of successfully working software that can be produced by an increasingly smaller and smaller sized team. Frameworks have specialized in lots of different areas and languages have gradually improved. You can get a lot done by clambering over the back of a giant’s head and it seems like the days of massive teams are increasingly edge-cases for the insane few.

Objects have won as both an accepted mainstream design and language construct, even surviving the barrage of whatever set-theory could be misused from relational databases. We even seem temporarily safe from top-down code generation tools (which I swear are correlated in their arrival by solar sunspot cycles). Sharing code is now more social and learning has been commoditized to the extent that a diaspora of interests seems normal. Not so many people are proud of just knowing a single language inside-out, but of the breadth of techniques they like to know and use.

The Future

The most simplistic thing I could do about predicting what would happen next in software development (the Oscar’s have now finished) would just be to extrapolate what we have seen over last 10 years and just project a straight line forward. This precludes new invention, which is never a good idea to bet against, but it’s still an interesting exercise.

On that basis, over the next 10 years perhaps we’ll see more temporary teams and self-employment. As teams get smaller, as frameworks get more specialized and productive then do we head for a future where we form temporary collectives of interest? A team can’t get much smaller than one, and while teams will still get together to collaborate, the future of software developers may well be more like Doctors, or Lawyers or Prostitutes (yes, let’s not talk ourselves up just yet)– specialized but self-supporting, collaborating but independent.

The combination of businesses not wanting to write their own bespoke software, of teams getting smaller and more specialized and of software production become more efficient (or at least repeatable). The story of Agile may not have been how to solve the world’s software problems but to highlight what is hopeless and what is achievable.

Cucumber

2011-02-10

Experiment! Danger! Beware! As you may have gathered, this blog is turning into an odd collection of writing. This one is certainly no exception, but I do plan to return to something closer to English next time. Good luck!

[file::features/blog_post.feature]

Feature: Talk about Cucumber
  In order to explore Outside-in BDD
  As a idiot non-savant
  I want to describe why I like it

Scenario: You don't get it, at all
  Given that this seems like a waste of time    
  When there is real code to write
  Then have a think about why you don't normally automate functional tests    

Scenario: No-one has told me what the Cucumber thing helps with yet
  Given that it's mentioned it in the title
  When so far all I've seen is a sort of Shakespearen sonnet-bot on crack
  Then there should be an explanation of what Cucumber does and why it helps
  But stop with the weird text layout


>cucumber features

(::) failed steps (::)
Failing Scenarios:
All, especially this blog post

[file::features/step_definitions/explanation_step.rb]

Given /^that this seems like a waste of time$/ do p "

The thing to consider is that this isn’t about testing, it’s about working incrementally by describing the behavior in a human-ish Domain Specific Language. The tests act as markers of your progress, and the failures act as the pointers of what to do next.

 "
end

When /^there is real code to write$/ 
do  p "

Which now has the advantage of linking the description of what you want to do to the real code.

  "
end

Then /^have a think about why you don't normally automate functional tests$/ 
do p "

Functional tests are tiresome and they break because they are brittle, in that they don’t link and live with the code but are produced as a separate thing that then takes on a life of its own. By placing them as part of the work process, as the driver for the work, then you get the advantage of tests too.

The behavior description helps you work out what to do and the tests then help you have the confidence to change the behavior over time.

  "
  response.should contain("Oh, I get it - cool. Can I go now?")
  assert(false)
end

Given /^that it's mentioned it in the title$/ 
do p "

Yes, there it is. In the title, I’ll get to it in a bit – honest.

  "
end

When /^so far all I've seen is a sort of Shakespearen sonnet-bot on crack$/ 
do p "

Yes, I know. I’m actually starting to regret it too if that makes you feel any better.

  "
end

Then /^there should be an explanation of what Cucumber does and why it helps$/ 
do p "

Cucumber is a ruby DSL (the grammar is called Gherkin, of course) that describes simple steps of behavior that then map onto specific tests as part of your steps definition. It works really well when combined with things like Rspec2 and web test automation such as Capybara or webrat.

I like Cucumber because it has filled a gap for me of avoiding getting into a rut early on in terms of ‘Why am I asserting for 1 == 1’ style testing and being intrusive (in a good way) on how I was doing TDD. I’ve found that it helps clarify what I want to achieve in code before I write too much, and liberates the feeling of racing ahead too many steps.

The ‘Out-side in’ style has been very useful to avoid too much over-design too early, and the tools light enough not to get in the way. If you get the opportunity to try it then I recommend it.

  "
end

But /^stop with the weird text layout$/
do p "

Ok, I’m done now, plus this was just an excuse to write about BDD using BDD. If it still doesn’t make any sense then here’s some links I’ve personally found really useful:

http://cukes.info/

http://railscasts.com/tags/7

http://www.pragprog.com/titles/achbd/the-rspec-book

http://www.engineyard.com/blog/2009/cucumber-introduction/

http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/

"


>cucumber features

Pass, well, if a 'D' is still considered a pass nowadays.

Obvious Software Trends for 2011

2010-12-31

At this time of year the usual suspects wheel out the prognostications and predictions for the coming year in software trends. It takes a special blend of arrogance and painful vainglorious lack of self-awareness to predict the future in public; you’d have to be a complete fool to do so:

Here’s my predictions for software trends in 2011 – The Easy Ones But It’s New Year’s Eve And I’m Going Out Edition!

Lots and Lots and Lots of JavaScript. Javascript used to be thought in a similar way to pornography, in that the majority of it is terrible but good enough for purpose, no-one admits to using it that much and, most of all, it powers most advancements on the web. At long last we’re seeing competition in browsers again, and the combination of performance improvements and local client resources being used, these things are pushing JavaScript into a credible programming environment not necessarily tied to just shuffling around DOM elements on a page.

My prediction is that we’ll see credible advances in more Server-side JavaScript frameworks, in that there has always been this tension between changing language between the HTTP hop and it seems logical that the tide might turn in the unexpected direction. JavaScript is a under-appreciated language and people are seeing more and more elegance in how it can be written.

It also seems likely to me that as well as faster browsers, better client resources usage and Server-side frameworks we’d likely see better IDE / programming environments appear for JavaScript – perhaps even proficient on-line editors that bring together DVCS teamwork (a la github) combined with ‘immediate feedback’ UI programming. The VB IDE created a noisy whirlpool of new corporate applications and it would be interesting to think what a HTML5/JavaScript/DVCS could do the same to democratize web apps too.

Things to watch in JavaScript land include various model frameworks, parallel network frameworks and various pre-processor like frameworks. There’s lots happening and if you’ve dismissed JavaScript as a ‘secondary environment’ or just something where your callstack disappears then it’s worth another look in 2011.

Mobile, Of Course. In some ways the Mobile years we’ve got coming up seem to smell of a do-over of what we’ve already gone through with desktop software. A fragmented market, different and always changing hardware bases and something where you try to predict the future off the back of how good the developer story sounds to you. Location, cameras and push events, coupled with a device that is intrinsically networked means that some crazy things are going to be tried and it’s an exciting sector to be in. Exciting can also be dangerous too, in that specialization in one platform or another is something that would be hard to bet the farm on. Porting apps is development hell where people who break builds end up.

My prediction in this space is more of a wish-fulfillment. I predict (or hope) that the mobile space starts to rally around the same advances we are seeing in browsers and JavaScript. I would very much like to see special features of phones and pads surfaced through HTML5 in a way that could flatten out all those hills and valleys of platform choice. I suspect that Android will have a very good year in 2011 and that it will take an advertising company to push this browser-centric basis through. Apple will make beautiful devices, Microsoft will make Exchange front-end devices, but Google might be crazy enough to keep cycling their mobile browser specs to take advantage enough of local device resources. The App store might live on, but it might be more of this rather than this. Lots of money and pointless apps will be made regardless.

NoStorage. In terms of overall system design choices the biggest disruptive change in 2010 was the new options around data access and persistence. The relational database is still the storage-du-jour, but with the greater awareness of caching and performance hotspots (memcache’s popularity, really using HTTP etc.) have spawned a whole host of new NoSQL storage options. The motivations for these new storages are all different even though they are grouped under one banner, in that some are about development flexibility of no-schema and explicit indexing of text, some are about through-put or sharding while others are about just plain avoiding disk.

I worry that guidance in the use of these options is still lacking, as many of these tools are so specialized that throwing one in early either smacks of over-early optimization based on a scaling hopeful prophesy or a naive assumption that Facebook’s architecture problems are the same as your architecture problems. It’s not dissimilar to the path we travel from ISAM to SQL, in that concurrency and scale drove a consensus to SQL but only after the options were thinned out a bit and people became confused on when to change from one to another. There is no ODBC for NoSQL. Perhaps, at long last, the quest of Persistence Ignorance features ORM solutions will help, in that rather than changing SQL vendor the data access method can now help hide different storage solutions for different read/write ratio categories of data.

My prediction in Storage is that we’ll see a marked increase of usage of NoSQL followed by an awkward hype-cycle re-adjustment as various things go horribly wrong. ‘Eventually Consistent’ is a phrase to be mulled over in light of practical experience of your data model and the saving grace of many SQL systems was there dogged determination to make anything with a query plan try to work.

What we really need in this area is an updated edition of Martin Fowler’s Patterns of Enterprise Application Architecture too, at least to describe the changes in the landscape we’re seeing shift around in this space. I’d like to predict that for 2011.

I’ve had a really enjoyable month back blogging, but due to unfeasibly large amounts of work and a mild obsession about writing, I now plan to take a short break and start up again in February. Thanks for reading and Happy New Year – have a great 2011.

Agile Plumbers

2010-12-24

Comedy Advisory Alert: I’m an agilist, perhaps not a good one, but agile methods still represent to me the best way forward in doing what we’re paid to do – solve problems using software as best we can. This post is inspired by the odd juxtaposition of comparing what we talk about in our day jobs as if there were like ‘real life’, as in what if the rest of the world tried to pull off what we do and say.

Merry Xmas everyone…

(Doorbell)

MAN

Ah, Agile Plumbers? Do come in, and thanks for coming so quickly – an emergency really, it’s a real mess in here.

PLUMBER 1

That’s no problem sir, we’re agile after all. Let me introduce to my two colleagues before I begin my initial presentation.

MAN

Presentation? Uh, do we have time – there’s water everywhere and..

PLUMBER 1

..we must insist sir. We want to ensure your involved as part of the business solution dynamic exploratory sessions. You’re our champion sponsor so to speak, our in-team consultant! Do you have a whiteboard we can use?

MAN

I don’t understand, surely this isn’t that complicated is it? Shall I show you where the water main comes into the house, I think it’s over here…

PLUMBER 2

Is there somewhere I can get undressed sir?

MAN

What?

PLUMBER 2

I need to sit in your bath – I’ll need soap and towels too. We operate in a Test Driven environment, Red, Green, Red. We’re behavior driven you see…

MAN

Why on earth would you need to that? There’s water flooding down the stairs, pipes are cracked, the toilet is backed up – can we please just make a start?

PLUMBER 3

That’s great feedback – thanks! Would you mind filling out these 3x5 cards – I’m especially interested in just the nouns at this point. Let’s iterate first on that flooding bit you just said…

PLUMBER 1

Let’s slow down a bit, the Domain Model can wait a little, let’s park that idea for now – we should write up the business needs some more, explore the motivations. Would you say all of these features are ‘business critical’ sir? Could you force rank the toilet? If you had $100 dollars…

MAN

Is this a joke? Look, if you guys can’t do this then..

PLUMBER 2

I’ll get the wrench then.

MAN

Good, at last! Hang on, you’ve just got one wrench between you all?

PLUMBER 1

No, of course not sir! I’m just here for the initial presentation, I’ll be leaving soon. I’ll still be very interested in the project’s progress though! I’ll phone in for tomorrow’s stand-up.

PLUMBER 2

Plus, to be clear sir, the two of us do share the wrench – we’re Pair Plumbers…

PLUMBER 3

..It’s more productive you see – we take it in turns to use the wrench. Keeps the quality high and provides us motivation to continue!

MAN

I don’t understand – you’ve done this before haven’t you? Isn’t the $500 call out fee enough motivation?

PLUMBER 1

You need to think big picture sir – consider this our journey together as solution partners. It’s very exciting! I’m super excited!

PLUMBER 2

Oh No. Look at this. Are these copper pipes? How many people live here sir?

MAN

What? The house is only five years old. It’s just my wife and I, but what’s…

PLUMBER 3

Hmmm. As I feared – it simply won’t scale! Oh dear. These are all legacy pipes, it’ll have to be all refactored out. These old things won’t fit with our new wrench too. This is looking NP- hard, as in No Plumbing…

PLUMBER 2

Ooo, we could use that new water tanking style system they have at the airport. There’s more work to do on the Big O ring performance profile but that would scale up to thousands of people here! I’d like to spike a NOSPIGOT storage iteration…

MAN

But..What?

PLUMBER 1

Perhaps we could feature you in a case study sir? We could really innovate here I feel. Let’s play a scheduling game while we let the guys brainstorm some patterns. What’s the simplest thing that could possibly work – do you have a bucket?

MAN

That’s it – I want you all out! This is ridiculous – you’ve obviously got no idea what you’re doing. Out!

PLUMBER 1

Sir, I’m beginning to suspect you don’t have a Facebook Social Platform Strategy for this solution at all?

An Overly Long Guide To Being A Software Architect

2010-12-21

This is from a blog post I wrote in around August 2005. At the time it got linked to a lot, read and laughed at in various degrees and even got reprinted in an industry magazine (but with vital professional edits such as my name being removed, I imagine to save billing complexity). In one of my ‘clear outs’ of online writings around 2008 I trashed the blog, but then late last week someone emailed me the text of the post they had kept. If for nothing else, it provides an odd glimpse back to my early Benjamin Button like computing career where I started at a 400,000 person company wearing a suit and worked my way back to being just me sat here in my Fez and fishing waders. As much as it pains me, and it’s deperately unfashionable skinny jeans terms, I’ve left it unedited – it’s still too long, but there it is.

An Overly Long Guide to Being A Software Architect

It is probably wise to start off with what I mean by the term ‘a software architect’. Well the answer is unfortunately quite oblique. It really is up to you. You may work on your own, you may work in a team the size of the Ben Hur extras but you may still be an ‘architect’.

The best I can do is say that it’s all to do with the breadth of responsibility you have for the solution.

Another more evasive but satisfying way (well, for me anyway, who has to type all this rubbish in) to answer would be for you to take a look down the list below and see if most of the items means something to you and your job. If they do, then chances are you may call yourself a ‘software architect’ if you so desired. Alternatively you could also call yourself ‘Supreme Commander of the Lesser Dominion of Greater Officetania’ if you like too; I’m happy either way.

Here are my top 11 bits of advice for aspiring and/or perspiring architects: (warning, this is a little long, so I’d grab a drink/snack and comfortable shoes now):

1. Politics. I put this first not because it’s the most important (there is hope still left in this world) but because it is the least discussed tangible thing that can make a difference. Nearly every book I have read on the role of the software architect tends to punt this thorny subject gently to one side. The general advice tends to be ‘The Esteemed Author doesn’t have this problem so recommends you getting another job, or something’. How nice for them.

Politics is a dirty word and brings images of an unshaven Nixon or of 22 year old MBA graduates in suits that are too big for them – but it doesn’t have to be quite like that. In most cases you need to sell ideas on their merit as well as your reputation. I have seen a great deal of genuinely magnificent ideas flail on the rocks due to misspent karma between peers. The corporate world is largely a playgrounds and the players much like children. People attach various weightings to people’s opinion based on their previous encounters as well as the opinions of you of their peers. If nothing else do try to realize that your actions with people have consequence. Relationships need to be nurtured. This doesn’t mean you go around inanely grinning at everyone like Tony Blair, but don’t ignore the fact that people need attention and listening too to – however impo®tant you may have become.

It was once remarked to me ‘Why do software architects listen so carefully to developers? It’s because they are watching their lips – that way they know when it is time to immediately start talking’. The best corporate politicians I have worked with have known when to shut up and listen and absorb.

Corporate politics is tricky, unscientific and dull but unfortunately it comes with the territory. What you need to do is face up to it, think about how you want to portray yourself, try to stay consistent and try not to take it all too seriously. Rather than going to buy that latest ‘C# SOA Gingham Patterns Revealed!’ book, take a walk on the distasteful side and go and read an old Dale Carnegie manual. That way you could have the brains plus the charisma and the good looks – and two out of three ain’t bad.

The software architect’s role is about 49% technical at best. Talk, listen, smooch, follow-through. Carnegie. Communicate. If you think that you are above politics, then you are wrong.

2. Perspective and Views. If I had to pick one tip to give on being a software architect I would say it was to remember the responsibility to take a series of views and a wider perspective on the system design – everything else is gravy. The nature of any complex system is to take a complex problem and functionally decompose it into modules and aspects. (Don’t get hung up on these particular terms, I just mean that there is a ‘zoom’ feature on a system design and that the architect is meant to be at a higher and wider viewpoint.) These modules and aspects are then strung together to make a system. So the architect’s job, and one that does get overlooked from time to time, is to go through the system design from many different perspectives and check that everything is still as good as you think it will be from different viewpoints. Remember that everyone else is busy beavering away on their various ‘next level up or down’ so you had better keep your head above the gopher hole.

The obvious perspective usually took is the functional path of how the system operates. Use cases are nearly always like this, which is why most people struggle when they start with the ‘UC1: User logs in’, as it required a series of non-functional decisions to be made up front. These non-functional requirements and constraints are usually the reasons most systems don’t perform well as they are harder to ‘mentally model’ from different perspectives.

I have seen very talented developers who have lost perspective or been in denial of a certain failing aspect of a system. These perspectives are never usually ‘forgotten’, as in ‘Oh dear, we forgot to add a secure admin interface’ but talked down in subtle group conspiracy of ‘not being that important’ at some stage of development. One curious thing is that this weighting of aspects is still more of a skill than a trade. Software architects can sometimes be like old army generals at a war college, in that they keep trying to fight the last war even if the battlefield has changed.

The rather tired but still relevant analogy is how an airline pilot does things different from a software architect. The two pilots sit at the front and ticks off a series of mundane sounding items (Flaps 10% – Check, APU standby – Check, Nice Hat at Rakish Angle – Check etc) even though they do this every single day of their lives, while an architect would happily do all this from memory even though they do it every 2 years. The difference isn’t in the brain power of the pilot vs the architect, it’s in the relevance importance of forgetting something. A slow web page hasn’t ever killed 200 people, just annoyed them.

So for me the trick with systematically checking your views is to adopt some sort of team methodology that suits your level of comfort. Maybe take a look at the Zachman framework, take a look at the old P. Krutchen 4+1 concepts pre-fatso-RUP or maybe just make up a checklist of all the perspectives on the system. Data Security, Bandwidth, Response time, Data growth, Integration are not the sort of things you can put on a design spec and ask someone to singularly ‘make sure they code it well please’, you need to go an purposely go mull them over up-front.

I know a lot of popular blogs that recommend an artisan craftsmen style of ‘if I wrote it down you wouldn’t understand it’, magic-circle style approach, but that doesn’t mean you can’t have a deliberate exercise of checking all your viewpoints and widening your perspectives to see if the system will work or not. Just because you are a Scrum Coach Lead Brownie doesn’t mean you can’t have some simple models and checklists.

Put another way, the primary role of the software architect is to be at fault when the system sucks at what it does.

3. Specialize or Don’t – But Do Decide. The classic bear trap for most software architects is to convince themselves that they can do everything well, or even ‘the best’. The approach of the architect is often to think of their job like an Olympic Decathlon event. All they need to do is run around monitoring everyone and offering tips to the sprinters, javelin throwers and pole vaulters on what to do. The flaw with this way is that a specialist can nearly always beat them in their respective events – and the generalist needs to remember and respect that. The problem is usually the architect came from a background where they were considered one of the best in a certain area, normally design/coding.

For what it is worth, I am a firm believer of trying to know enough about an area to have a representative appreciation of it, but of not trying to rule all the roosts. I have learnt to live with my limitations.

Team leaders can be good software architects, but you don’t always have to be the Glorious Leader to be the software architect. Great developers can be good software architects, but you don’t always have to be checking all the code. Put simply, this tip is to try and appreciate that your role may now mean you will have amentallossy-style algorithm for remembering the other team member’s particular skills or expert areas. If you consider yourself the team’s best Coder/Tester/Network Engineer/DBA/UI designer/Manager, then as a software architect you won’t be much fun to work with.

4. Patterns, Logic and Algorithms. People not in IT sometimes get the impression that this industry is radically overhauling itself with exciting new concepts and languages at a half-life of around every 2 minutes. While it is true that terms and technology keep the trade press busy, a lot of what we basically do more or less stays the same. Most designs can be expressed as a series of patterns implemented through a narrow set of algorithms. Once you get the basics ingrained then you can spot the similarities and speed up your learning-by-example process.

I came into IT from a maths and comp.sci background and felt that a basic understanding of stats, number theory and logic has, despite my grave and commercial misgivings at the time, actually been quite useful. I tend to side with those that think that introduction into systems is probably best from a non-vocational aspect, i.e. who cares what particular syntax and language you learnt as long as you got to experience a few of them.

So this tip is that the next time you get ‘syntax anxiety’ in that you can’t remember how to do something from memory in code XYZ, try to step back and find the essence of what is the same from what you already know. Rather than trying to be a complete C# generics expert next week, take a look at Eiffel or even Ada and look how they achieve polymorphic data-type signatures. Rather than review large pages of code or spaghetti models, try to step back and recognize what the base algorithm is doing. This exercising of your focus muscles is a useful skill for gaining perspectives as an architect too.

As an example, take a good look at how a proficient developer debugs a difficult problem, it is usually the same process and logic apply each time – regardless of the situation. If you learn this ‘abstract essence’ approach then the ongoing technology and language changes can get enjoyable rather than onerous.

As an aside I want to comment (yeah, because that’s exactly what this article needs is more words…) on two misconceptions I have regularly seen on the use of patterns in software architecture. Ok, here we go: (1) You not only have to identify them but you need to actually do what they say – I know this sounds trite but just because you can recite their name doesn’t mean you are helping. The code is the deliverable, the pattern was just there anyway. (2) patterns are a form of ‘language’ and if you sit there alone in your Grand PooBah office and talk to yourself about them then they lose an awful lot of their goodness. A shortened way of expressing something is only really useful if everyone actually knows what they mean – it is an oxymoron to be the team’s ‘pattern expert’.

5. New Technology Fetishes. I absolutely love technology, it’s a weakness, but it isn’t actually what an architect does. The dark side of technology is that you can tend to lose focus on what your original business problem was. A brand new set of shiny technology techniques tend to lead to zombified software architects wandering around the IT landscape looking to pin their new found toy onto a project that doesn’t move away fast enough – ‘BRAINS BRAINS XML XML’. We seem to all have an unbelievable faith in extracting out just the potential positives with something we aren’t that familiar with. It is remarkable how goldfish memory like our retention ability is of however bad the previous version was. I see this as akin to childbirth memories in women, if anyone remembered how truly bad it really was then we as a race would only ever have one child, i.e. game over humans. The body has endomorphines, software architects have MSDN Magazine?

The tip here is to make sure you contain yourself and your enthusiasm when presented with an unfamiliar technology. Pilot it, research it, go slow if you can – but don’t just go and rush to 3rd base with itjust because your friend said they did.

6. Build vs Buy. In today’s cornucopia of frameworks and platform features one of the most difficult architectural decision is on whether to build or buy major parts of your system architecture. On one hand it is quite liberating to have all the difficult decisions taken away from you and that you can’t go and tar-pit yourself into a Don Quixote chase of rewriting your own mini relational database. The other side of the coin is that nearly always by making an ‘embedding’ decision you are actually changing the systems requirements in a way that might not be obvious at the time. If you don’t have the mandate to make that sort of compromise then the inflexibility of a buy decision can be painful. You can get a lot out of buying components or frameworks but you must quickly shift into the attitude of knowing where the sweet spots are – in other words, ‘Stay On The Path’. There comes a time where you stretch the original metaphor so far with what you bought that you just need to hold you hands up and say ‘enough’. It seems to be a harder decision to drop a bought subsystem or framework that it is to first adopt one.

Very few teams are just reams of pure virgin code anymore – they now start from a level of having to understand a set of libraries or application model. As a software architecture your familiarity of the constraints and the ‘normal path’ is very important in this respect.

My general advice for build vs buy as part of a software architecture is to make sure you know what you are getting into and that you probably has an obligation to try not to invent anything. The painful contradiction here is often that clever architects want to innovate and that for the vast majority of business cases they probably shouldn’t be – at least not in the area of choosing what to build themselves or buy.

7. Resources, Money and Economics. The amount of money to spend on a project is the ultimate non-functional requirement but rarely gets explicitly discussed with architects. Practically every decision you need to make can be traced back to how much or how long. As the software architect, whether you like it or not, you will have a constraint of what you can do with that money, even if you don’t have direct budget control. One unobvious and often unstated goal of a software architect is to give excellent value for the money to your employer.

Money also has a large bearing on what Build vs Buy decisions you need to make. It is a strange thing now I think about it, but I have seen many more over-architected systems than ‘under-architected’ ones, as in they just lacked features but worked very well. The norm seems to be that they over-extend what they need to do. In economical terms this is a curious situation, in that like a child with a new crayon set we seem destined to try to used every single colour regardless of the picture. Some architects seem to naturally fight the constraints of budget and run-time license costs, as if they weren’t part of what they do. Well they are and you can chose to have a voice or just complain. A lot of methodologies would do well to stress plain old stuff like return-on-investment rather than the more exciting.

In terms of advice for aspiring software architects in terms of handling resources is to make sure that they fully understand the economics of what they are trying to succeed at – it may be an incredibly dull subject but you might just implement a successful system for the people paying for it and be allowed to do another one.

8. Requirements and The Domain. It is no accident that the most common business domain that software developer feel they could start up their own company in is in the area of software development tools. The ideal thing about a source-code trees or bug tracking products is that you can reality-check everyday that your product is sweet without having to interpret with someone that doesn’t understand software development. (Of course the irony of this is that you then try to sell to a market that ultimately doesn’t really value your tools as they rather foolishly think they could do an ad-hoc themselves or just make do. Cobblers and their children’s shoe is the pertinent saying, I imagine. The other outcome of the dev market is you just end up with a set of small but really smart customers, and that can present it’s own set of commercial problems way beyond the remit of this ditty.)

For the rest of us that don’t actually day-to-day need to use the systems we develop then need to form some sort of relationship with people that do. I don’t have a table of stats to show you but I personally have a deep feeling that software projects fail in two main ways:

(a). The system doesn’t work that well.

(b). The system works well but doesn’t do what you need it to do.

By and large it’s mainly always (b) in that it missed the need of what is actually useful. But it seems that we as an industry seem to concentrate our collective brain power on solving (a) much more though. The Agile approaches seems to at least attempt swing the game back into admitting that we can’t really go that long before doing the wrong thing, but in my limited experience, it often seems to just accept that this developer-domain gap exists as an unavoidable ‘tax’ to be amortatized over a short set of more rapid releases.

You can go either way with trying to understand the domain problems as a software architecture. You can choose to fully surround yourself with them in an attempt to understand them more, or you can trying to step right back and just call them ‘Widgets’. The danger with not getting involved with the business requirements is that it is tragically easy just to hear what you think are justifications for the architecture you have in mind. This problem is also compounding with the fact that if it takes 6 months to gather the requirements then they are probably not going to be correct in six months time. Requirements are a 4-dimensional problem.

The first part of my tip for the software architecture in terms of the requirements is to at least spend as much time listening to the users as you do your implementation team. Also try to actively look for aspects of the system you know are difficult to implement and go around with active questioning on those early on. If you passively ask a user what they want then consider that they might not actually know, but they will still say something.

Setting expectations with the users is a double-edge sword in that a lot us of can’t down-play the system to such an extent that it gets cancelled versus the more likely reality of placing some limits on what can be achieved. Good software architects can actually say ‘No.’ though, it just takes some finesse.

The second part of my tip is try to resist extensibility because of open-ended requirements. This is very hard and it is so tempting to add points throughout the system design where you try to foolishly anticipate growth. If you talk to a user and give them the following options:

Please tell me what fields you need on the Insurance form

Do you need user defined fields on the Insurance form?

I mean, what would you say? What is the least work and safest thing for them to answer with? You may already have in you mind that this glorious architectural adventure of a system will need variable data-structures, so you can quickly get to into a mutual deadly embrace of you both wanted to do more than is strictly wise or necessary. Of course it then goes bad for both of you, but the User can safely just say that the requirements have evolved.

9. Trust and Communication. Trust is the key to not going insane in any sort of team. As a collective sliver of an industry it is my observation that software architects are rarely good at delegating or handing off. There is nothing more pitiful to behold than a single person being mentally Slashdotted was a ‘knowledge bottleneck’. You can tell the signs of a person thrashing to disk with their brains and it’s not fun to watch for anyone concerned.

The software architect is not the Central CPU of the Tron movie or even that ‘Ergo’ bloke from the Matrix. You don’t have to be some walking giant brain that knows all the answers. The primary job is not to know all the answers but to know someone that does. If you can’t clearly and plainly communicate what you mean then you aren’t much good to people.

As a software architect if the core of your team can’t all decently describe the intended architecture through the stages of development then, in many ways, you have failed in your job. The tip here is to remember that the team, however large or small, is what makes the software and that conception and orchestration are important roles that have a limit like any other in the team. Practice explaining what you are intending to do to people above, below and sideways from your position. I have never heard of a software architect that failed for talking or trusting too much.

10. Learning. Like this article, It Just Never Ends. Some people have the impression of a software architect as being some higher level pinnacle of a developer’s career ladder, in that once they get there then things will be easier somehow. Well, here’s the good news and bad news – the pace of learning never lets up. The only way to cope with this is to try and get into the mindset of continually learning and enjoying the feeling of not knowing something.

After a while it gets quite Zen-like and you start to recognize the cycles of the older ideas being given new names. If this bothers you then just have to try to relax – it terms of emotional involvement with what you do for a living there are few jobs as enjoyable as being a software architect.

11. Advice. Finally my last tip is to never take advice from Top 11 tip lists. In nearly all cases there was only about 3 good points and with about 8 padding. Here’s a proof: The movie Pearl Harbour was 240 mins long and had the same amount in duration of edutainment as this article; it also cost ~$200 millions dollars to make. The comparative maths would then be p = 240/200 * 0 < 3/0 * 1. Actually I don’t know what this equation proves, but I really didn’t like that movie.

Ruby and Rails for Attractive .NET Developers

2010-12-18

Warning: This post might not be any good. These are my personal observations of using Ruby and Ruby on Rails after about six weeks of use, which means: (a) In a similar way to a Chemistry degree freshman in their first semester realizes that everything they were ever taught at High School was actually a lie, I await all my mental abstractions to come tumbling down and (b) I am still at the theme park ‘Wow, that ride was Awesome!’ level of objectivity, and this post is being written from the gift shop you must walk through on the way out.

Here’s some of my observations so far:

Expressive. Ruby is expressive. Jim Carrey on amphetamines dressed as a French mime playing charades acting out ‘Oklahoma!’ level of expressiveness. It absolutely loves strings, and isn’t embarrassed to acknowledge that the reality of most programming tasks is to endlessly shuffling around characters. The String class has at least 4E24 methods (exercise left to reader). The evil genius of regular expressions has been institutionalized to the extent that you can use them directly as literals, which depending on how comfortable you are with regex expressions, is either a blessing or a Tourette’s Syndrome glimpse into an otherwise very natural language code reading style. @@_x =~ $& isn’t a cartoon expletive, but is often how I say it out loud.

Ruby’s names allow you to travel fully over a modern keyboard – you can using characters like ? and ! in method names to indicate intended behavior. It’s a language where you can express your intent in English, albeit someone who occasioning splutters too many secret symbol combinations. The code is typically terse but very readable once you get past the initial learning hump. The language’s reserved words set is very small, but you do get the feeling that as each new idea has been added, and with the internment of regex, that every non-alpha symbol is destined to be special. If you ever gave up on vi or vim without even printing out a cheat sheet then you may find Ruby initially awkward.

Idioms. Ruby has more idioms than Hans Christian Andersen’s grandmother. It has a strong sense of style that is encouraged rather than enforced. Ruby is an adult-orientated language, in that you can tell it has been developed by people who have really lived in the clothes of other languages and want to improve. It is unusual to read really bad Ruby code, and it’s surprisingly consistent given its flexibility. I’m not sure why this is, but would guess that it’s a ‘Second Marriage’ attitude of many of the community, in that Ruby is not their first time around the block. Blocks and closures allowing behavior as a first class objects, method-as-message passing attitudes around duck typing and enumerations rather than outside loops all contribute heavily to the feeling that what is considered high-falutin' CS concepts in other languages are now mainstream normality here. If you are a C# developer that hasn’t internalized LINQ yet or a Java programming who couldn’t describe generics without a Google search then Ruby is either a great new opportunity to reset or a potential house of horrors depending how much you want to bend your brain muscle.

Useful Introspection. Reflection and the VM environment are two areas that are worth highlighting in Ruby. (As you probably have gathered by now, this isn’t a tourist language tour, it’s more of a random postcard – I recommend this if really want something authoritative to read here). If you are used to a half-static language then it is disorientating to see how introspection techniques are used in real code. The first time in Rails you see something like this:

find_by_username(user_name)

..and then realize it’s a dynamic finder that relies on a method_missing to go look to see if ‘username’ is an actual ORM attribute before turning the expression to

find(:first, :conditions => ['user_name = ?', user_name])

..was a happy moment for me. Ruby is the Domain Specific Language run-time that I’ve always wanted.

Note: Rails especially loves symbols (that :first name thing above) as they make great hash keys amongst other things. A symbol is an interned string (made unique in a map) often used as a ‘lookup’ to an existing identifier. More real info here. I’m not sure why Ruby doesn’t have named parameters yet (See disclaimer up top on my ignorance), but the language certainly seems alive and active, in that perhaps the next version will?

The monster in the closet of all this dynamic evaluation and duck typing has often been touted as performance. This is, in my opinion, a fallacy. Your developer environment and production environment are not the same, nor should they be. They serve two separate purposes and can run in very different and specific ways. Ruby and framework’s like Rails re-enforce this separation. It is hugely productive to be able to alter your codebase while running your code in development – and if you’ve ever made a cup of tea every time you compile a large code base you should understand exactly what I mean here. When you deploy to production your run-time should match your needs, but not as a developer. This evaluation of dynamic finders time will not be significant in a realistic production run-time if your application is doing something non-trivial. Measure, don’t guess or assume. Let go of any prejudices.

The concept of compiled executable images being performance profiled on your desktop machine, and the language bottlenecks showing up like flies to swat is not helpful anymore. Whether your target is web, mobile or actually even desktop, relying at a language level intuitive measurements for performance is a mistake. You can write bad or inefficient algorithms is any language, sit waiting on a read access for too much unfiltered data – you don’t need Ruby to do that for you.

Rails. Rails is really Ruby’s significant other and the main gateway drug to active Rubyness due to it being a big ol' lump of real-life Ruby to go stare at and see working. I write web apps, and what I want to do fits well with how specifically Rails tries to solve that problem. The real ‘Rails trick’ seems to be understand first what Rails is meant to help you with before committing to it. It’s not just a DSL for making a blog in 15 minutes or even a twitter clone, but nor is it as general as you might think – make sure you want to walk this path, as fighting it isn’t fun.

The most pleasant surprise so far for me in Rails-land has been the active Gems community. This open-source extensibility attitude is probably the single most productive enabler for me around Rails at the moment, in that I spec up a feature I need and then often find anything common enough available as an existing engine, gem or plug-in.

If you come from the Microsoft world this is a refreshing thing to see, in that these ‘components’ (for want of a better word) are chiseled by real world use, born out of a realistic business need and have to survived the Darwinian process of selection in the big wide world. Bad or useless code of course exists, but that can just be ignored or not forked. Good things bubble up, bad things are not made into must use ‘corporate standards’. The ecosystem is also very varied, and not focused on one particular tier i.e. ‘UI Grid Component Version X – Now For UI Technology N+1!’. A lot of the ‘aspects’ side of a system design have been offered as extensions, in that you can reuse gems for database models (Active Record over NoSQL solutions are fashionable in that ‘Look Ma, No Disk!’ kind of way), as are things like authentication, authorization, markups and logging and the like. Rails 3 has made significant in-roads into extracting itself from all-encompassing design decisions in these areas and the raw choice is impressive. A few years ago it would have been ok to say that Rails and it’s extensibility captures the architectural patterns in ways that formal top-down authoritative-style frameworks have repeatedly failed at, but the naughty ‘Big A’ word has far too many connotations nowadays that I’m too afraid to use it.

Home Is Where The Shell Is. The natural developer home for Rails seems to be a Mac. More specifically, a brand new Mac Airbook carried in a European soft-leather carry all containing an expensive men’s face creme, a Lonely Planet’s Guide to Reykjavik on $10 a Day and an iPhone 4 filled with 16GB of smooth sweet jazz. Either that or any distribution of linux works fine too. My main point here (other than a backlog of Rails stereotype jokes I can’t do anymore) is that Windows is not its natural environment – you can probably get it to work fine in the end but expect some needless nailing of jello to walls. If you are curious but on Windows then I can recommend either VirtualBox or just use Wubi till you want to create another partition – they are all good. O/S’s all work the same (Discuss: 20 pts), and you will survive without intellisense (and yes, there are ruby IDE’s that do this too). Embrace your inner vim/emacs.

So far I’m on my second semi-major Rails web app and an important side of these first thoughts is that I’m still enjoying the whole environment enormously. The code I write is specific to my problem domain, which I think is where we all need to be heading.

It is interesting in that a lot of the ‘magic’ side of Rails is actually not that mysterious at all, in that it follows the idioms of Ruby and that whole stack is still vibrant, changing and moving forward. At times it seems chaotic, but I think that’s part of why it’s still alive and kicking. So far so good.

Time To Diversify

2010-12-01

After many years I’ve decided to change nearly everything I do in terms of software development. This blog will be used to help me record that journey. Either that or I’ll fail quietly and remove all pointers to its existence – but let’s start positive and try not to spoil it all in the first paragraph.

/Skippable background… just imagine some wavy-line ‘going back to the past’ script.aculo.us animation here please, as it’s late already

I started out in around 1989 using HP-UX as my ‘work platform’ and being freshed-faced, annoying and reasonably clueless; as is the specialty of CompSci graduates throughout time. Given a small amount of dangerous knowledge I reeked havoc using my dual weapons of C and vi. After a few years, by more or less chance, I tripped over something new to me called Microsoft Windows. It had no credibility at the time but had the lofty aim of being ‘For Workgroups’ and even the LAN had it’s own Manager – it seemed legit albeit a bit ‘Noddy/Micky Mouse (delete where applicable). Everybody at work laughed at it and swizzled their long beards at its lack of more or less everything Unix had. OS/2 perhaps stood a better chance at that time, but having worked for IBM during college, I knew they alone had the sheer power of massive ineptitude to go ruin it and snatch failure from the jaws of PC victory.

At the time the hardware that we used to sell as part of the system’s my employer worked on was criminally expensive kit – huge cathode ray specialist monitors, expensive graphical workstations and luxury mice: We were at the time of the hardware being the majority of the cost of a bespoke system purchase, with the software carved out by spotty upstarts such as I on the cheap (I lied about the fresh faced earlier).

It seemed obvious to me then that I could champion the PC and Windows, I could push an agenda where the hardware vendor and those expensive custom equipment would be defeated by comparatively cheap beige boxes of PS/2’s, WM_ messages and tiny fishbowl-like monitors. I spent all my energy trying to convince people that Windows would be the future and we should move our products across. I tried to do good, for a good cause and make a lot of money – not necessarily in that order.

/End of long self-indulgent wordy retrospective

After about 20 years of that I sit here back at a Unix prompt (a very purpley looking one, but still) with no .NET, no Windows and no Visual Studio nearby.

Before I go on I should probably state that, tragically, this is no angry and bitter rant or rage against some corporate monster. It would probably be much more entertaining if it was. I still think .NET is a great piece of engineering, that C# is a good language and that the people I know from Microsoft are smart, courteous and relevant. There are also groups of very smart people pushing the better work and design ethos up that hill in that community and moving things ever forward. I very much enjoyed being a Microsoft Architect MVP for all those years. In summary, ‘It’s not you, it’s me’

The macro reasons for moving on to other platforms is in a constant quest to become a well-rounded ‘full stack’ developer. To be able to see the good and bad in different languages and platforms and use that experience to improve. There is so much good stuff out there that it would be criminally negligent of me not to go explore some of it while I have the opportunity.

I like to imagine that somewhere in Redmond there is a small office facing the rainy car park where a junior PM is tasked with recording reasons for people leaving the Microsoft development ecosystem. Here’s my thoughts for the benefit of that person:

The last bastion of ‘used in corporate development’ will crumble, it just takes longer. If .NET is what people do just to ‘get employment’ then eventually even ‘work’ will start not to use it. The long-standing prediction of the AlphaGeek is coming true. Where you ‘code for fun’ is ultimately where you’ll end up, and people who just do it for the money get left behind. ‘No-one gets fired for using X’ was meant as a derogatory comment the first time around.
The web is going to win. There will always be desktop apps, phone apps, console games and various specific scenarios. Win in those area’s all you want, but never deny that the choices today for web development are nothing like the choices we had 5 years a go. You could still make the best ever web platform in the history of software but that fact is the chances of consolidation like we saw in the Win32 days isn’t going to happen again. The choice geni is out of its browser bottle.
The Bazaar is more powerful than the Cathedral. I’ve been amazed, excited and humbled by the amount of goodness I’ve found on github recently. I’ve always known about sourceforge, the way linux came together and various on-line code sharing sites/methods but things are now reaching a crescendo. I spent about 5 months recently working with python, some with of it on Django and more recently in the last couple of months with Ruby and Ruby-on-Rails – this ability to read others code, reuse other gems and packages goes far beyond any work of art a single religion could build. It’s not the quality, it’s the quantity – the choice and pure Darwinism selection of what’s on offer is changing things in an important way. I’d like to be in that party, and not helping organize a similar one by watching what happens through the window.
License costs make no sense to me now. I try to run a business, I hope that business will be successful. If I can do what I want to do without paying for server software, for databases or for development environments as I grow then why would I? We’ve reached the level where the level of choice in so many different areas of software development and deployment have commoditized things. The distinguishing features that make one clearly better than another are not enough when arguing with the bottom-line of $0. License costs when put against the stark reality of rentable hardware in abstractions like dynos or VM’s just make it seem worse. There will always be a place for the buying and selling of software, but the underlying web platforms may not be it.
Innovation is random and unpredictable and everywhere. I think that Microsoft does innovate; I think things like monads in C# via LINQ, pushing MVC as part of ASP.NET and the adding of F# to visual studio are all great examples of this. Here’s the thing though, great ideas are happening everywhere and it makes no sense to look in just one silo or from one parent. There’s node.js, there’s jquery, there’s MongoDB, CouchDB, there’s Haml and Sass, there’s the elegance of reading RSpec and Shoulda and describing in Cucumber, there are DSLs for all manner of domains – I could go on and on and on. I want to learn everything. Now some of these new things will fail, some will be average ideas but not significant; but they are where smart people are all trying to improve how we write software. I would prefer to be an ordinary fish in a wonderful aquarium rather than an expensive old fish in the market. Microsoft does great things, but it’s become safe and dependable rather than exciting and risky.

As mentioned above, I’ve got some things I want to share about various things I’ve learnt on projects over the last 6 months or so using jscript, python and ruby but this isn’t the post for them. There are probably a few experienced Microsoft developers doing what I am am doing, and it would be good to share war stories.

While I’m sure I’ll be desperate someday with a ‘Will VB.NET For Food’ cardboard sign sat slumped outside an insurance company, today is not that day – this is my Adios .NET post.