Archive for the ‘ThoughtWorks’ tag
I went to watch the latest ThoughtWorks Australia Quarterly Technology Briefing in Sydney on Wednesday where my colleague Lindy Stephens, Suncorp’s Josh Melville and Lonely Planet’s Nigel Dalton presented on ‘Agile Governance – Managing the Enterprise Issues‘.
I was actually unsure of how interesting it would be to me as the title seemed a bit dull but it was actually quite entertaining and not at all what I expected.
These are some of the things I picked up from the presentation:
- Lindy started out talking a bit about the illusion of control that waterfall plans can lead us to, referencing the intial paper on waterfall written by Winston Joyce which actually criticises the idea of designing everything up front and suggests an iterative approach would work better.
A recent article by Tom De Marco where he retracts the idea that you “can’t control what you don’t measure” was also referenced. The most interesting part of this article for me is where he points out that projects which provide minimal return are the ones that need the most control but perhaps we should be considering whether we should even undertake them in the first place.
The idea of having software that is production ready at any time is also a very nice thing to aim for:
So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product.
- Traditional measurements of progress derived from a more waterfall process actually only tell us if we’re proceeding not if we’re succeeding – it’s much more useful to keep our focus on whether we are delivering value to the end user instead of just focusing on whether we have hit our targets on delivery date and promised scope.
The transparency and visibility that we typically have when following a more agile approach was mentioned by a couple of the speakers – progress is much more visible throughout and we don’t suddenly have a project going from status ‘green’ to status ‘red’ right at the end.
I think we need to be a little bit careful that we explain things carefully when showing this types of data to people who are new to the agile approach as it can very easily give the impression that we are totally failing when actually it’s fairly normal for initial progress on a project to be slower than it will be once we get going.
Nigel Dalton described a story where even the Lonely Planet chef knew how one of his teams was doing because the information was so transparent!
- Nigel also spoke about the idea of outsourcing agile and suggested that the best way to ensure success with this is to work with people in a country on the same longitude so that the timezone difference isn’t too great. He also suggested that having people from both locations going to the other works well for ensuring better communication.
- The general idea behind what Nigel presented seemed to be that the individual teams effectively provided the governance of projects and that it wasn’t necessary to have massive reports detailing progress every week.
Josh Melville stressed the importance of looking at the value of all documents and getting rid of them if they don’t provide anything useful. Nigel described how they had massively simplified one of their reports after listening to Josh’s advice!
Lindy pointed out that sometimes we’ll be executing projects in an agile way in environments which more traditionally follow a waterfall methodology and that in this case it might be necessary for the project manager to spend some of their time converting the data into an appropriate report.
In terms of the lean approach this seems to me to just be waste, but perhaps a necessary waste.
- Josh also talked about the importance of moving away from a process centric view of the world to a relationship based one when it comes to managing projects whereby problems could be talked through instead of just writing off a project as doomed because a ‘checkpoint’ wasn’t reached.
He also suggested that considering whether we delivered features and also whether they were actually used were more useful things to look at rather than looking at budget and time.
- In the questions afterwards one suggestion to the speakers was that the metaphor of software development as being similar to industrial manufacturing is not really helpful and that perhaps movie making is a better one to use because there is a level of creativity involved and the aim is to deliver something of value each day.
Nigel pointed out that while traditional manufacturing didn’t have much to teach us, lean manufacturing was a different story as it helps us cope with variation rather than just cost which is quite important in software development.
There seems to be quite a few books out at the moment about how to introduce a more agile approach into your organisation – I’ve been reading Lean-Agile Software Development and Becoming Agile and there is also a book called Scaling Lean and Agile Development – so I was intrigued to see whether the messages from this talk would be similar to those in these books.
What did I learn?
- I often find when listening to Martin Fowler speak that although what he says is quite similar each time when speaking about agile there always seems to be something different that stands out for me each time.
This time what stood out was his mention of the Dreyfus model with regards to people’s level of skill when it comes to agile – when you first start out as a novice it’s quite hard to keep the principles in mind so you spend a lot of time focusing on the practices and getting better at these but if you want to keep improving then at some stage you need to move up to a level where the principles do become more predominant.
- Andy made an interesting point that IT and in particular software development is pretty much made for people who want to learn new things and he also pointed out the myth that ‘learning finishes at school’. I never really considered this before but for me it definitely applies – the process of learning new ideas appeals far more to me than the results and outcomes of projects so it was interesting to hear this coming from someone else.
- Transparency with regards to bad news was something else which was pointed out as being fairly important and it’s certainly an area where we often run into trouble – often organisations aren’t used to bad news being delivered to them early and they get the impression that if it’s going badly now then it’s going to keep on going badly, rather than seeing that it’s quite good to get bad news early because then you have time to fix it.
- Martin described the ‘pilot project anti pattern‘ which he has come across where organisations make use of agile on a project which noone really cares about and use it as a training ground. It was suggested that this is not an effective way of introducing an an agile approach as it doesn’t matter to anyone so there’s no incentive to work out whether the new approach is really beneficial or not.
- I liked the question that Andy posed about success and failure. He first of all asked anyone in the room who had seen an email from their CEO talking about a really successful project and congratulating the team to put their hands up. Pretty much the whole room did.
He then asked who had received an email from their CEO talking about a failure and the lessons learned from that and only one person’s hand went up!
Andy is definitely right when he suggests that “if you’re not failing you’re not learning anything” and this is something which I’ve also come across from Andy Hunt in Pragmatic Learning and Thinking and more recently I’m trying to get into the ‘improvement ravine’ with regards to learning F# as I’m still writing object oriented F# which I think is missing the point a bit. Thinking in a more functional way is the key for me there.
- A question was raised about how agile can fit in with fixed price projects at the end where it was pointed out that if the price and the time are fixed then the scope has to be variable – it can be infinitely flexible. It’s actually often the case that a lot of value can be delivered with reduced scope even though it doesn’t seem that way when you’re told that all three of them are fixed!
I’ve been reading quite a bit of lean related material lately but I thought it would be interesting to hear about it directly from the perspective of two people who have been involved with applying the concepts in organisations.
What did I learn?
- It was pointed out that lean thinking is particularly relevant at the moment with the global financial crisis requiring organisations to come up with more effective ways of operating with little cash at their disposal. Toyota of course derived the Toyota Production System when they were in big trouble and needed to find a way out of their own financial crisis in the 1950s.
- Lean is not just about manufacturing, it is being applied in many other industries as well. Paul pointed out that KMT are introducing it to the service side of many organisations. I think it is a different challenge introducing it into software development and while the Poppendiecks have written some excellent material on lean software development, there is still more for us to learn about how to do this successfully.
- Although I’ve read quite a bit of material about lean I’ve never been convinced with the normal definition that I hear of lean in that ‘it’s about reducing waste’ but I didn’t have a better definition until Jason came up with ‘it’s about engaging everyone to solve problems‘. It does still feel a bit generic but I like it better than the other definition.
- The most interesting part of the presentation for me was when Jason spoke about the different types of waste in lean in terms of software development:
- Extra features (Over Production)
- Delays (Wait and Queue) e.g. waiting for business sign off of stories
- Hand-Offs (Internal Transport) e.g. passing work onto someone else
- Re-learning (Over Processing) e.g. the same problems coming back when we have already previously learn about them. The first time we find a problem that counts as learning.
- Partially done work (Inventory) – e.g. work requiring late integration which hasn’t been done yet. At an extreme I think this could be taken to mean any work which isn’t in production since it is only when we put something into production that the value from it is realised.
- Task switching (Motion) – e.g. doing several projects at the same time. Here we end up with the problem that all of these projects are delivered late. Jason pointed out that just because people are busy doesn’t necessarily mean they are adding value.
- Unused Employee Creativity
The book ‘Learning to See‘ was suggested as a particularly useful one for learning how to identify waste.
- There was mention of set based concurrent engineering which Brad Cross has an excellent post about. The idea is that when there is doubt about the best solution to a problem we pursue several different options at the same time before deciding on the best option at the last responsible moment.
- Jason spoke about the difference between authority focus and responsibility focus, the latter being a more lean approach where we focus on ‘What is the right thing to do?’ and ‘How can I help?’ rather than the far more common approach I have noticed of ‘Whose job is this?’ and ‘Not my problem’. If we can get the responsibility focus going then suddenly the working environment becomes much more pleasant. Related to this I quite liked Liz Keogh’s recent post where she talks about rephrasing the language we use when talking about problems to avoid the blame culture.
- Value streaming was also mentioned with relation to how our goal is to find added value for our customer and that most organisations only achieve around 20% of value added activity in their value streams. A comment which really stood out for me was how ‘no problem is a problem‘ in lean thinking. People like to hear good news and you can often be referred to as being negative when you point out problems. In lean we recognise there are going to be problems and get these raised and sorted out as soon as possible.
I first came across this book when I was browsing Andy Hunt’s Pragmatic Thinking and Learning: Refactor Your Wetware on Amazon. It showed up as one of the related books.
I had expected it to be a more theoretical book than it actually is. It is full of really useful command line tips and ways to use system tools and IDEs more effectively. It only took until page 3 for me to learn something from this book – a short cut for navigating Firefox tabs which I now use all the time. Apple Key + Tab Number (Mac) or Ctrl Key + Tab Number (Windows) takes you to the appropriate tab for those who are intrigued!
The first half of the book (Mechanics) covers general power user tips and tricks for using your machine better while the second half (Practice) is more about ways that you can be more productive as a developer.
I will summarise some of my favourite parts of the book and the most interesting things that I learnt from reading it.
- I have often wanted to learn how to use the Unix command line properly – I know how to do basic operations but nothing spectacular – but I found it difficult to work out how to make full use of it short of pairing with an expert. Having read this book I have learnt some excellent tips that I wouldn’t have come across otherwise.
- The idea of shims – little pieces of code that you can write to solve small problems – is the standout idea in this book for me. I often find myself repeating the same boring manual steps without even considering that there could be a better way. This book completely changed the way I think about these types of tasks.
- I thought I had a pretty good idea how to use a lot of the tools on the Mac but Neal shows so many different ways that you can improve your effectiveness with them. The book lists innovative ways to make use of QuickSilver, the Clipboard and Shell and also includes links in the footnotes to applications referenced in the text. This is something I haven’t seen done in a book before but it’s a really good idea as far as I’m concerned.
- Neal explains how to use open classes in Ruby when creating fluent interface DSLs and finally I now finally understand why extension methods have been introduced into C#. When there are code samples these are annotated and then explained in detail. This certainly made it easier for me to follow some of the examples around using the Unix shell and Ruby.
- Neal reminds you of things that you probably know but need reiterating. The ‘angry monkeys’ story is a particular stand out with regards to this. This covers the idea of always challenging why things are being done a certain way and not accepting ‘because this is how it’s always done’ as an acceptable answer. There is an interesting example used with regards to using underscores in test names as suggested here.
- The chapter on Composed Method and SLAP (Single Level of Abstraction) when writing code was especially good – I knew of the concept but I didn’t know there was a pattern named after it. My reading around this led me to an interesting post on the Arrow Head anti pattern – this is what the code can end up looking like if you don’t keep to one level of abstraction.
I found that the best way to read this book was to read a bit of it and then try out the suggestions on the computer. It’s not really a book that you can read on the train for example.
I would rank this book up there with The Pragmatic Programmer as one that I would recommend all developers read. There are so many tips in it that you are bound to find some that you didn’t know about and your view of automation will be much broader having read it, which can only be a good thing.
I was an automation junkie after reading The Pragmatic Programmer, but after reading this book I think I’m going to become even more obsessive about it.
As a side note this is the first time I’ve tried to write a review of a book on the blog. Feedback on whether doing it like this is useful or better ways that you’ve seen it done would be gratefully received.
While reading some of the rough drafts of Apprenticeship Patterns online I started thinking about the stages I have gone through on my Software Development journey so far.
I have worked in the industry for just over 3 years; 1 year at Reed Business and 2 years at ThoughtWorks. Over that time my thoughts, opinions and ways of doing things have changed, and no doubt these will continue to evolve as I learn more and more.
My time at RBI
I started working at RBI in August 2005 a few months after I finished University. My experience up to this point involved several years coding PHP in a very procedural way and a little bit of Java.
I was hired by RBI as a C# Web Developer and my work there involved working on several internal projects and looking after one of their websites.
At this stage I was still very much convinced that the art of software development lay in learning languages, so I used to spend all my time reading about C# and playing around with all the different APIs.
At this stage I was using Visual Studio without Resharper so I didn’t have the ease of Refactoring or moving code around that I now take for granted.
One of my colleagues took me under his wing and started teaching me how to write better code – separation of code across presentation/business/data layers was my first lesson. Suddenly it became so much easier to make changes! All the code I wrote was still in a non TDD way and after one episode where I created a bug in production I started to think that surely there was a better way to develop software.
Eventually my colleague suggested to me that if I really wanted to learn how to write software then the best place to do so was at ThoughtWorks.
I thought I had a fairly good idea of how to write Object Oriented code but that theory was quickly disproved as I went through Object Boot Camp as part of my TWU training. The Single Responsibility principle was the overwhelming lesson learned as part of this. I also remember believing at this stage that it was all about Design Patterns.
I came back to the UK and did a couple of small projects where I first came across continuous integration and TDD before going onto my first big project.
I remember my first day on that project involved pairing with Darren Hobbs and being amazed at the speed with which he was able to move around the code using IntelliJ. It became clear to me that I had a long way to go.
Working on this project for the best part of the year I learned a lot, including how to write code in a Test Driven way, that everything you do in software is a trade off, but most importantly I learned how to master the IDE – if you can do this then you feel more confident and you can complete tasks much more quickly. This is always the advice I see given to new Graduates at ThoughtWorks – learn how to use your tools!
I moved onto my second project where I was immediately surprised at how much easier I found it to move around the code base than I had at the start of my first project.
We were designing a client side application so a big part of my learning here was around testing presentation logic. Jeremy Miller’s blog proved invaluable at this stage.
It was also the first time I came across the concept of Domain Driven Design – it was amazing how much easier it was to develop software when the developers were using the same language as the BA, QA and in fact the business. InfoQ’s cut down version of Eric Evans’ famous book proved useful in helping me understand the concepts that I was seeing in our code base. I remember thinking at the time that I didn’t need to bother reading DDD as it was all covered in this version – I was wrong!
We had an very lightweight version of Agile being used on this project – we tried to have minimal process and do as many things as possible just when we needed them. It was almost Lean in nature although this was never explicit. It was interesting to me how easy and fun software development could be when it was done like this.
My third project was the first time that I got the opportunity to work with legacy code – i.e. code that hadn’t been unit tested. My early lessons on trade offs came back to me here as I realised that not writing unit tests is a trade off – you can choose to go more quickly initially by not writing them but eventually it comes back to haunt you.
I was working with Alexandre Martins on this project, and his enthusiasm for writing clean Object Orientated code gave me a new outlook on writing code. Working with him got me in the frame of mind of hating exposing the internals of classes and constantly looking for other ways to solve the problem when I was considering doing so.
Halvard Skogsrud’s knowledge around concurrency was another eye opener for me around how non functional requirements should have an impact on the way that software is designed. It also introduced me to the way that other languages such as Erlang handle concurrency – and behind this the idea of having as much of your code immutable as possible to avoid threading issues.
During a debate at a ThoughtWorks Geek Night another colleague brought up Alistair Cockburn’s Hexagonal Architecture, which was the first time that I had come across an Architectural Design Pattern. This is a useful technique when thinking about the design of systems at a higher level.
On my next project I did a lot of work around build and deployment which gave me the insight that developing software is about more than just the code. This was a lesson first taught to me by Chris Read a year before but it finally made sense to me.
A big part of this project was inter process communication between different components of the system which introduced me to the idea of event driven messaging. I immediately saw the benefits of this over the RPC style messaging I had seen previously.
I also had the opportunity to do some work with Ruby on Rails and in particular around the use of Active Resource. This introduced me to the idea of RESTful web services which feels like a much more natural way to communicate over the web than any of the other approaches I have come across.
The interesting thing for me is that I didn’t plan to gain any of these learnings, they came about as a natural progression from my interest in software development and from working on different projects with different people.
The biggest things I have learned since I started working in software development are that it is much more an art than a science and that there is no right or wrong, just trade offs that we should be aware of.
I still have a lot to learn but I thought it would be good to have a look at what I’ve learnt so far in the hope it can help others just starting out on their journey.
It would be interesting to hear about others’ journeys and the similarities and differences you have experienced.
It seems programmers are taking a bit of a hammering this week!
Kris Kemper talks about the Net Negative Producing Programmer referring to a paper linked to by Jay Fields, concluding that the code submission is very important in helping to distinguish between good and bad candidates.
Now I probably haven’t done as many interviews at ThoughtWorks as Kris has but from what I’ve seen of the recruitment process it seems to be more focused on ensuring that potential hires culturally fit into the organisation rather than that they write the best code that anyone has ever seen. Clearly a level of ability in coding is important for a Developer but I believe that the ability to communicate and collaborate with your colleagues is even more important. It’s quite a rare situation in software development where you have to develop something completely on your own, and even if it were to happen you would still need to communicate with your customer even if the development effort was solo.
Bruce Eckel has an interesting post about hiring technical talent where he lists several criteria for hiring people, ending on the note that organisations should not hire people he terms as ‘toxic’. A toxic person according to his description is someone who has some kind of quirk that causes destructive behaviour. In other words someone who is likely to destroy the morale of any team they are placed in by their actions.
I think ThoughtWorks are getting the balance right in hiring very talented people who are able to collaborate with each other to solve problems. One client even said to me that they did not understand how every single ThoughtWorks person they met was so nice. I think that is a glowing recommendation for looking at the overall personality of candidates and not just raw coding ability.
One of the first unusual (to me) things that I noticed from the trainers at ThoughtWorks University was that when they were listening to participants they would often ask questions and re-frame the participants’ comments. Intrigued and impressed by this I spoke to one of the trainers and was told that they were engaging in ‘active listening’. Wikipedia defines the term as follows:
|Active listening is an intent “listening for meaning” in which the listener checks with the speaker to see that a statement has been correctly heard and understood. The goal of active listening is to improve mutual understanding.|
I believe this is a very useful skill to acquire, and I certainly hope to improve my ability in this area.
It reminded me of the 5th Habit that Steven Covey speaks of in his book titled ‘The Seven Habits of Highly Effective People’: Seek First to Understand, Then to be Understood. Certainly easier said than done…but then again we do have two ears and only one mouth so perhaps there is a good reason for that!
Browsing the ThoughtWorks Blogs yesterday evening I came across a link to an interesting site which spoke of the ‘Eight barriers to effective listening’. I found this particularly useful as not only does it point some of the common problems one can have when listening to someone else, but also suggestions as to how these can be overcome.
A couple of months ago I read a book titled ‘Coaching Yourself to Leadership’ – although I found it quite heavy going in places, it too touches on some listening barriers, namely:
|Advising: After hearing only a few words, you believe that you know how to solve the person’s problem and you start offering advice.
Comparing: As you listen to the other person, your insecurities get triggered, and you start comparing yourself to the person—assessing which one of you is better, more knowledgeable, more competent, etc.
Daydreaming: You get triggered by something the other person says and you’re off in your own world. You don’t have a clue what the person said to you.
Derailing: You find the subject matter uncomfortable, so you abruptly change the subject or interrupt with a joke.
Filling-in: You don’t let the other person finish her sentence; instead you finish it for her.
Filtering: You only listen to the part of the message that is important to you, and tune out the rest. You either pay attention to things that might be emotionally threatening (and fail to hear anything good), or you only hear what is good (and fail to hear the parts that are negative).
Identifying: You identify with what the person is telling you and swing the conversation back to yourself, telling how something similar happened to you. You become engrossed in telling your story, and don’t really listen to the other person or allow her the space to continue her story.
Judging: You make hasty judgments about people before completely listening to what they have to say.
Mind Reading: You look for what you perceive to be the truth, and end up making assumptions that have little to do with what the person is actually saying to you.
Placating: You want to be nice and supportive; therefore, you voice agreement with everything that is being said, even if you don’t really agree. Because you don’t really want to disagree, you don’t listen deeply enough to fully examine the other person’s viewpoint.
Rehearsing: Rather than listening, you are mentally preparing what you are going to say. You might look interested, but you’re really concentrating on planning how you’re going to respond.
Sparring: You quickly disagree with the other person because you have a strong point of view. The other person feels like she hasn’t had a chance to be heard.
I hope this is ok to post on here – I’ve just written up the points straight from the book. Copyright of the author Peter O’Brien and all that.
I know I do at least 3 of those, and that’s being kind to myself!
One of the most interesting things I have discovered since starting at ThoughtWorks earlier this month is the emphasis that is placed on giving feedback.
The first lesson we were taught about giving feedback was that it could be one of two types. Either it should Strengthen Confidence or Increase Effectiveness.
In Layman’s term that means that if you want to make a positive comment about somebody’s contribution then you should make reference to something specific that you believe they have done well so that they can continue doing it. Equally if you believe there is an area that they could improve it, a specific example of this behaviour/fault should be noted along with a suggestion for how they can improve.
As a member of Toastmasters since January I was already used to this concept of feedback and there are certainly parallels in the feedback system encouraged at Toastmasters and that used at ThoughtWorks.
Although Toastmasters do not define types of feedback, there is an expectation that evaluators will apply themselves in a certain manner when carrying out their job.
One of the things which is frowned upon is known as ‘whitewashing’. This is where an evaluator would say that a speaker was ‘brilliant’ or give a summary just using complementary adjectives. Although the speaker may well be flattered, it does not really tell them anything or leave room for improvement. The use of the word ‘brilliant’ or ‘superb’ is only the perception of the person using it, and the failure to make use of the word with regards to a specific behaviour or action means that it is rendered meaningless.
Equally when the evaluator believes there is an area that the speaker can improve in they should make a reference to the specific negative behaviour or action so that the speaker can recall their mistake and go about making the improvement. When giving feedback it is very poor practice to attribute your own feelings to the speaker – you are giving them control over something which they do not have control over! For example, if an evaluator were to say: ‘I felt bored listening to your speech, you should make the next speech more interesting’. In this case the evaluator is giving the speaker the power to make them feel bored. It is ridiculous to let someone have that amount of control over you and if we consider that another person listening to the same speech may have felt really engaged, a property of the speech cannot be that it was ‘boring’.
This is very similar to the way that ThoughtWorkers are expected to give feedback, although it is also emphasised that when giving feedback one should speak only for themselves, and not try and speak for a group of people. Doing this would assume that mind reading is possible and as far as I’m aware this feat has yet to be achieved. An example of committing this mistake would be to say something along the lines of: ‘It would be better for us if you could do x’. In this case ‘us’ is not defined and it is unlikely that one person can speak precisely of the feelings of other people.
This concept is very similar to that of Generalisation in the NLP Meta Model, which states the following:
|“Generalization is the process by which elements or pieces of a person’s model become detached from their original experience and come to represent the entire category of which the experience is an example.”|
This is an area that I am actually working on myself, and I am finding it very difficult to speak only for myself because I’m so used to generalising! Of course there are still times when generalisation is vital, and we would find it very difficult to live our daily lives without generalising on some things. Giving feedback, however, is one area where this ‘technique’ is counter productive.
I had heard stories about how inheritance could be misused but I didn’t think I would be stupid enough to fall straight into that trap! We were taught the concept using ‘Measurement’ as the problem domain. So to translate the previous sentence into English: The aim was to design classes which could handle old school measurement types such as Inches, Feet, Yards, and so on.
I went about the task by first creating a base Measurement class and then created Inch, Foot and Yard as sub classes of this. The code looked pretty slick to me and I was quite pleased with how it had turned out. I was feeling pretty confident that I had nailed the objective of the session. Alas, it was not meant to be!
Upon reviewing the code my partner and I had created, one of the trainers pointed out that the sub classes did not actually do very much at all. They were effectively useless classes and there was barely any difference between them! One of the other requirements for the code was that it should be possible to compare an instance of the Inch class with an instance of the Foot class, an instance of the Yard class with the Inch class and so on. No problem I thought and promptly created methods called ‘ConvertToFoot’ in my Inch class and ‘ConvertToInch’ in my Foot class.
One of the cardinal sins of object orientated programming had been committed! I now had 2 methods which did almost the exact same as the other for no additional benefit. What if there were 100 different measurements? That would mean 99 different conversion methods each to convert to all the other types of measurement. Clearly not an optimal solution – I had taken the bait and fallen into the trap of over use of inheritance.
Anyway, the lesson of the session was that in this particular case it was better to use delegation or composition. In this example it means that there is only the need for one Measurement class, each instance of which comprises of a Unit object. The concept of a ‘slug’ was introduced – no not one of those nasty little insects, but in this case meaning an instance of an object with a private constructor and one public static instance. In other words slugs are like a poor man’s Singleton. The code looked something like this:
public static readonly Unit INCH = new Unit(1);
public static readonly Unit FOOT = new Unit(12);
This made it far easier to add future measurement types, and meant that only two classes were needed instead of a potentially infinite amount.
I read an interesting article on this topic by Robert Martin, titled ‘Template Method & Strategy: Inheritance vs Delegation’ which explains the reasoning much better than I have here along with a code example.
I’ve always found it fascinating watching people who really excel in their field going about business, be it footballers, tennis players, actors, whoever.
This week at TWU I’ve been playing around with some Ruby on Rails as I mentioned in the previous post, and yesterday I had the opportunity to watch one of the leading figures in the Ruby on Rails field at work. Take a bow Obie Fernandez, who gave several of the TWU attendees a demonstration of how to develop applications using Ruby on Rails. It was actually bordering on the severely impressive watching the speed at which he thought through concepts and then transformed them into code.
I also realised that the way I’d been using the language previously had been dubious at best. I hadn’t realised that you can take care of database creation without using MySQL Administrator, nor had I realised quite how ‘clever’ Ruby on Rails is at mapping database tables to models created in the application.
It was almost painful watching how simple it is to do arduous tasks, such as creating textboxes and drop down boxes, in Ruby on Rails and it almost made me want to weep as I recalled the many hours I’ve spend using PHP and C# tweaking interaction between code and stored procedures/queries.
So +1 for Ruby on Rails and I certainly hope to improve my ability with it over the next few weeks.