Pages

Thursday 5 May 2011

DDD - a cute suggestion for naming of repositories

Tonight I've been messing around with some code in a TDD code-kata fashion, coding for practice as much as anything else. I decided to start to implement an order management system with CMS-like functionality, as a home project I could use to keep my interest over many nights of toil.

Anyway, I started to create a repository class - see Eric Evans Domain Driven Design (DDD). This class would be responsible for handing me my SalesOrder aggregate root entity from some obscure infrastructure that my domain didn't need to know about. I found that I was struggling with what to name this class. I was torn between SalesOrder (which seemed more pure domain language-ish but could cause me later confusion between that and my SalesOrder entity, and SalesOrderRepository (which gave me the separation I craved but didn't seem to fit with Uncle Bob's clean code naming guidance, nor Evan's ubiquitous domain language!).

I Googled around a bit as is my wont, and found a really interesting webpage. Let me share with you what it advised:

Instead of calling my repository either SalesOrder or SalesOrderRepository, what if I called it AllSalesOrders. This is:

  1. Very domain languagey
  2. Forces me to remember at all times that I am operating on/with a list
  3. Gives me some really elegant looking client code like allSalesOrder.For(customer) and allSalesOrder.ForDeliveryOn(date)
  4. Makes it pretty darn easy for me to spot when I've broken the single responsibility pattern allSalesOrder.AddCustomer(customer)

Sunday 17 April 2011

Motivation 101 - what is it, why do I crave it and how do I get it?

So today I've been reading around the subject of motivation. I'm mostly concerned about how I can get a better level of motivation from my team, but if I can learn the tools to motivate a few other people around me at the same time, so much the better!

What is motivation anyway? You cant touch it, you cant buy it (not directly anyhow) and you cant seem to train it in. For the purposes of this blog, when I say motivation, I mean passion, dedication, enthusiasm and all of those other words that in the workplace roughly translate as someone who enjoys their work and so goes the extra mile to make a really great job of it.

Thursday 14 April 2011

The importance of a good working environment

So, a couple of things have happened at work today to make me think about how much the working environment can affect the quality and speed of our delivery.

Tuesday 12 April 2011

5 ways to make yourself a better software developer - without learning a new tool, process or pattern

Without resorting to stereotype, developers can sometimes focus their time and energy so much on the tools and the code, that they struggle with the softer side of the job including communication, teamwork & planning. In the workplace this can cause friction and be to the detriment of the product or delivery.

In my experience, there are a few things that you can do as a developer to combat this problem, in yourself and in your peers:

Saturday 9 April 2011

Agile

So this week, like a viral you tube clip, this old blog post from Steve Yegge did the rounds in my team.

Thursday 31 March 2011

Belbin's perfect team

Dr Meredith Belbin put forth a hypothesis that for every problem to be solved by a team of people, there exist nine distinct roles that each team member would have a natural psychological leaning towards a subset of. Furthermore, Belbin postulated that for a given problem type/complexity and known make up of a team, the success of the team could be predicted.

Management Philosophy

I often beat myself up because time and again I fail to really solve the problems within and surrounding my team. What I try might go some towards my goal, other times the solution I come up with might make no discernible difference, and as a rare occurrence, even make the problem worse.

Tonight I'm feeling more generous towards myself, and the events of the day have helped me reach the following conclusion: Like in Philosophy, there is value in knowing the important questions, even if you cant yet see the answer. As in Philosophy, there is enlightenment to be found by peeling back the layers and dismissing those things that are definitely not the answer.


If you, like me, occasionally stumble your way through myriad ideas, concepts, tools and technologies (all of which purport to make team working more productive, more efficient or just more), then tonight - just tonight, give yourself a break and a pat on the back for giving a damn and never giving up.

Wednesday 30 March 2011

People matter

If I could offer one bit of advice to a software developer, nay anyone who works with other people towards a common goal, it would be that people matter.

What this blog is supposed to be

Having worked in software development for more than ten years, I have developed a lot of opinions & beliefs, but one stands out amongst the crowd: "You can have the best and latest tools in the business, but unless you have a group of people committed to a quality delivery, using processes that are comfortable and supportive, then your delivery is doomed."

With this in mind, my intention with this blog is to talk about the things that, over a ten year period, have made the difference. I'm not a guru, I dont have all the answers, but I do have opinions borne of experience, and I offer them freely for dissection and discussion.

Who am I? My background is in Microsoft bespoke development, latterly using .Net technologies. I have used many software development methodologies on projects ranging from tiny to Enterprise-ready and I now lead a small team of developers and continue to push for better and faster.