Navigate / search

Simplicity

Ladies and Gentlemen of the class of ‘14

If I could offer you only one tip for the future, simplicity would be it. The long term benefits of simplicity have been proven by Rich Hickey whereas the rest of my advice has no basis more reliable than my own meandering experience. I will dispense this advice now.

Beware the over engineered complexity of your code; oh nevermind; you will not understand the over engineered complexity of your code until it bites you in the ass. But trust me, in 2 years you’ll look back at code you’ve written and recall in a way you can’t grasp now how much unnecessary gold plating you added and how little it really achieved.

You are not as smart as you imagine. Don’t worry about designing for the future; or worry, but know that worrying is as effective as trying to solve an algebra equation by chewing bubblegum. The real troubles in your design are apt to be things that never crossed your worried mind; the kind that blindside you at 4pm on some idle Tuesday.

Do one thing everyday that challenges you.

Refactor

Don’t be reckless with other people’s code, don’t put up with people who are reckless with yours.

Contribute to Open Source.

Don’t waste your time on jealousy; sometimes you’re ahead, sometimes you’re behind the race is long, and in the end, it’s only with yourself.

Remember the compliments you receive, forget the insults; if you succeed in doing this, tell me how.

Keep your old source code, throw away your old performance reviews.

Automate the tests

Don’t feel guilty about not knowing the right way to build software, the best developers I know didn’t know at 22 the best way to build software, the really good ones at 40 still don’t.

Get plenty of sleep.

Be kind to your laptop power supply, you’ll miss it when it’s gone.

Maybe you’ll make MVP, maybe you won’t, maybe you’ll join a startup, maybe you won’t, maybe you’ll go into management at 30, maybe you’ll be pushing code to github on your 75th birthday whatever you do, don’t congratulate yourself too much or berate yourself either your choices are half chance, so are everybody else’s.

Enjoy your development tools, whatever they are, use them every way you can, don’t be afraid of them, or what other people think of them, they are the greatest toys you’ll ever own.

Deploy, even if you have nowhere to do it but in your own living room.

Read other people’s code, even if you don’t understand it all.

Do NOT read “The Clean Coder”, it will only make you feel dirty.

Get to know desktop app development, you never know when it’ll be gone for good.

Code in C++ once, but stop before it makes you hard; code in Ruby once, but stop before it makes you soft.

Speak at Conferences.

Accept certain inalienable truths, complexity will rise, frameworks will not meet all your needs, you too will get old, and when you do you’ll fantasize that when you were young code was simple, frameworks were great and developers respected their colleagues.

Respect your colleagues. Don’t expect anyone else to do your work for you. Maybe you have an unspecified deadline, maybe you have a 10X team member; but you never know when either one might run out.

Don’t mess too much with your process, or by the time you get around to writing code there won’t be enough time to write any.

Be careful whose advice you buy, but, be patient with those who supply it. Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than it’s worth.

But trust me on the simplicity.

Aha! Unit Tests – DDDBelfast

Sample Code

On Saturday I spoke at DDDBelfast. My Session was on Unit Testing. After the Test Driven Development session in Bristol, it occured to me that a more fundamental problem was Unit Testing itself. Whether the Tests are Written before or after the code is a non-issue if developers aren’t writing automated Unit Tests at all.

Here are the slides for the session.



The sample Code includes the Wizard project which includes a suite of Unit Tests, you’ll need to install MOQ and NUnit to run all the tests.

Also included are the three examples of injecting mocks, and the example of how traditional NTier code can violate the Single Responsibility Principal, and how to avoid that problem

Any questions about any of this, feel free to get in touch or leave a comment.

Test Driven Development – Pushing Through The Pain

Sample Code
TDD Sample Code for DDD South West

Last weekend I presented a session on Test Driven Development at DDD South West in Bristol. I actually presented the session twice thanks to being voted onto the repeat track, and in total I had 120 brave souls who came along to see the session.

I’ve taken the past week to go back over the sample code that accompanies the session and tidy it up a bit, add some ‘discussion’ comments about various issues, and also factor in a few suggestions that I received on the day.

The code can be downloaded from the link at the top and bottom of this post. The slides can be viewed here:



Thanks to everyone who came along, that especially to everyone who left feedback, and virtually everyone did. This session started with a 90 minute running time, I cut it to 1 hour for DDD South West, but it still felt a little rushed. My hope is to cut it dramatically in time for DDD North (if I’m fortunate enough to be invited) and cover less ground, but in more detail and with more time for interaction and questions from the floor.

If you have any problems with the code, or if you’d like to point out some issues with it then leave a comment or find me on twitter (@richardadalton).

Thanks for stopping by.

Sample Code
TDD Sample Code for DDD South West

DDD South West 3

It’s 11.30, I’ve got work in the morning, I’m knackered and I’m still sitting in front of a computer having just tried out some things that I picked up at DDD South West over the weekend. That’s the effect that participating in the DDD community can do to you. It recharges those tech/geek batteries and for a few hours or a few days programming feels a little like it did when I was 15.

If there’s a downside to being a speaker it’s that the preparation for speaking sucks up a lot of time (at least it does if you need to prepare like I do). So things slide by un-researched or not studied properly. Having spoken at DDD Scotland last month and now DDD South West, with two different sessions, I’ve been heavily focused on DDD for about 4 months, while things I’d like to look at more closely like Threading and Rx for example haven’t gotten the attention they deserve.

The flip-side of this little faustian pact is that when I get to DDD I make up for lost time either in sessions or more often in the informal chats and demos (un-sessions as Paul Stack calls them) that spring up around the conference itself.

As usual on the day I didn’t get to see many of the other sessions. In fact I only saw Colin Mackay’s session on Parrallellization (I, like Colin hope I spelled that right, probably didn’t, but don’t really care.).

My latest project leans heavily on Threading but uses the older syntax. I haven’t had a chance to really look at the new (not so new any more) threading syntax, so this was a session I didn’t want to miss. It didn’t disappoint.

Within a few minutes of flopping into the recliner after the long trip home the laptop was open, and I was trying out some of the stuff Colin had shown us. I’m really blown away. I had touched briefly on the issue of Testing Threaded code in my TDD session and this is an area that I’m going to be spending a lot of time on over the next year or two.

I reworked my sample code using the new syntax and not only did the intent of the code become clearer, I removed all of the locks I was using (probably incorrectly) and at the same time removed an intermittent race condition bug that was in the code.

Apart from Colin’s session the only others that I attended were my own. I was on deck twice thanks to my TDD talk getting voted onto the repeat track. In a quirk of scheduling I presented on the Repeat Track before I presented in my originally scheduled spot.

The repeat track was presented in quite a small room. It got the day off to a nice start to be presenting to a full room, we had to turn a few people away and ask them to come to the main session later in the day.

The main session was in the Track 1 room, which is a pretty big room. That also felt pretty full, which suggests that there’s a real appetite for TDD, which is odd because in many ways things have moved beyond TDD and the focus has switched to BDD and so on. I wonder if the opinion shapers in the industry have perhaps gotten bored of something and moved on just when the mass of developers are only just catching up and really getting interested. I think I might try and stick to my philosophy of speaking about out of date topics and see of there continues to be a market for it.

I did have a slight fear that a TDD session could end in tears (if not mine then someone elses). At an event like DDD there’s a strong chance that the audience will include a significant number of people who fall into one of the following categories.

1. People who know more about TDD than I do, but come along for a look.
2. People who hold diametrically opposed views to mine, regardless of my views.
3. People who haven’t really gotten into TDD but have already been turned off by the hype.

It can be hard to include anything in such a session that will see any of these people come away with anything of use.

I’m sure there were some in the audience who got very little from the session, there always will be and I hope they left feedback so I can include some things for them, but I was delighted to receive some very kind commends from a number of people who I really didn’t expect to have benefited from the session.

Funnily enough I speak at these conferences in the hopes that I’ll energize a few developers to try out things like TDD, and I come away energized myself. Strange how that works.

The un-sessions were as always brilliant. An informal demo of TeamCity by Paul Stack addressed a few issues I’ve been having, and I got to show him my favourite simple trick – the miracle of creating a text file with a UDL extension and then double clicking on the icon.

A few people approached me with questions and suggestions about my session which I’m going to incorporate before I release the slides and code.

At the Geek Dinner on Saturday night I had endless fascinating conversations, from a chat about recruitment with Tim Gaunt who’s responsible for the brilliant http://borninthebarn.co.uk/ to picking Colin Mackay’s brain a little further on threading, to the usual round table moaning about how you can never have enough monitors to the best ways of encouraging community participation and on and on.

Retiring to the pub led to a fantastic chat with Graeme Foster about where technology will be in our kids lifetimes, and their kids lifetimes, to where we’ve come from (ZX81s and the BBC Micro). We talked for hours and never got around to talking about the thing we met up to talk about – Domain Driven Design.

From pub back to hotel and an oddly circle of chairs let to a long discussion on topics as wide ranging as The Rapture and Creationism, 80’s Rock Legends and how to impersonate them, Restaurants with strange bathrooms, Oldest, Youngest and most interesting birthdays, and most famous namesakes, Sci-Fi TV shows, various attempts at Pun inspired humour that resulted in threats of physical violence, all leading to an analysis of the lyrics of the Spitting Image Chicken Song with particular emphasis on the best order in which to accomplish the tasks outlined in said song.

The party broke about after 1am, and I went back to the room pondering the notion of an 8am for a taxi to the airport.

This morning (Sunday) as I slinked down to the lobby with a few minutes to spare before the Taxi arrived, I found a handful of DDD’ers getting through breakfast.

If you are not already part of this Community then sort that out at DDD North in Sunderland on October 8th. If you’re a software developer and you are not participating in some way in the wider development community, you really are missing all the best bits.

Thanks to everyone who grafted to make DDD South West go smoothly. I hope to be back in Bristol this time next year with an even better session.

Aer Lingus vs Ryanair

I’m currently getting ready to present at DDD South West in Bristol on June 11th. In addition to the normal work of creating sample code and slides, I also have to figure out flights and a hotel.

In the past I’ve tried to avoid Ryanair. There was a time when it was actually worth paying a little more to fly with Aer Lingus. That’s no longer the case.

I don’t know if it’s the 25% stake that Ryanair owns, or just an inevitable progression in the airline industry, but I can no longer see any difference between Ryanair and Aer Lingus.

That’s not true. There is one difference. The price. Aer Lingus seems to be embracing everything about the Ryanair business model, except the price.

Let’s look at an example.

I’ve just booked return flights to Bristol with Ryanair, flying from Dublin at 21:15 on the 10th of June, returning at 10:55 on the 12th.

The headline cost of the flights were €3.99 each way. Ryanair add a Web Check-in fee of €6 each way, giving a total of €19.98

On Aer Lingus, the cheapest outward flight is €4.99, but it leaves at 6:25 on Friday morning. Of course that would mean missing a day of work and being at the airport at an ungodly hour. There’s an 18:45 flight for €14.99.

But let’s take that €4.99 flight, it makes the comparison more interesting. That’s €1 more than the Ryanair flight. There’s a €4.99 return flight on Sunday, also at a stupidly early time. How does this extra €2 pan out if we proceed to try and book the flight?

As I mentioned, with Ryanair we add a further €12 euro for a total cost of €19.98. You’d imagine the extra fees would be pretty similar for Aer Lingus right? They are departing from and arriving into the same airports after all.

I was stunned to find that Aer Lingus charge €19.99 EACH WAY in “Taxes and Charges”.

Think about that. The Taxes and Charges EACH WAY on an Air Lingus flight cost more than the entire cost of a round-trip ticket with Ryanair.

What are these Taxes? What are these Charges? Why don’t they apply to passengers flying with Ryanair?

And we haven’t even gotten to the extra fees for credit card booking etc.

One of the things that annoy people most about “Low Fares” airlines and indeed other businesses is the extortionate fees for paying by credit card. The online business model allows companies to radically reduce their overheads, but rather than pass on those savings they charge customers for the “convenience”.

With Ryanair and Aer Lingus the fee for paying by card (as if there were another option) is €6 each way, per ticket. Not per transaction…Per Ticket, Per leg of journey. That’s €12 for a return ticket for one person.

Unlike Aer Lingus, Ryanair usually has at least one type of card which allows you to avoid this charge. Annoyingly they keep changing it. I’m in luck this week, I have a prepaid Master Card that I bought at Christmas, and Ryanair allow it to be used without charging the €12 fee.

With Aer Lingus the fee is also €12, but there doesn’t seem to be any way of avoiding it.

So, to sum up.

Ryanair, Headline Ticket Price €3.99 each way. Final Total €19.98
Aer Lingus, Headline Ticket Price €4.99 each way. Final Total €61.96

Some day, very soon Aer Lingus will cease to exist. I don’t know what it’s final demise will look like, but it will vanish. When that happens there will be much hand wringing and questioning about how such a thing could happen.

The answer is simple and we’ve known it for a long time. Aer Lingus is taking the piss.

How to build a framework and why you almost never should.

Sample Code
WizardFX

Above is a link to the Sample Project for the “How to Build a Framework” session that I presented at DDD Scotland. Below are the Slides. There’s a good deal of information from the session that isn’t in either the slides or the code so I’ll be doing a full write up as soon as time permits, which will probably be sometime after DDD South West in June.

As always please remember this code was written to demonstrate certain ideas, it isn’t production quality code, use it if you like, but don’t expect too much from it.

Incidentally some of the accompanying tests will be discussed in my Session on Test Driven Development at DDD South West.



And here’s the feedback I received from the attendees in Glasgow who were kind enough to fill in the feedback forms.


DDDScot "Frameworks" Feedback
DDDScot "Frameworks" Feedback

DDD Scotland 2011

Last weekend I headed to Glasgow to speak at DeveloperDeveloperDeveloper Scotland.  My third DDD, my first as a speaker.

The speaking experience is a little different.  I presented during the last session of the day which meant that for the entire day I was “yet to speak”.  Which meant that I spent a good deal of the day sneaking off into quiet corners to run through the slides, or look at some source code.

I also gave a quick Grok Talk on Fitnesse, although I could have passed on that, I spoke last which meant I was still speaking as people flooded back into the room for the after lunch sessions.  A case of one Grok too many I think, but no harm.

I was pretty happy with how my session went. “How to Build a Framework, and why you almost never should” seemed to go down well, it drew a larger attendance than I had expected, considering the excellent sessions that were on at the same time.

The session feedback was very positive.  One or two people suggested slowing things down and spending more time looking at the sample framework. These are two things I was conscious of going in.  Despite cutting huge chunks of what I’d like to have covered, it was still a push to get everything into the 50 minutes or so available.

In retrospect it would have been better to talk less, demo more and give a good write-up to cover anything I couldn’t get to on the day.   Let’s see if I can put that into practice at DDD South West in Bristol next month.  It’s a completely different session, but one I’m looking forward to…”Pushing through the pain of TDD”.

In the meantime, watch this space for the slides, sample code and write-up of the Frameworks Session from DDD Scotland.