Wednesday, 18 January 2017

Be Humble

Some of the best developers I know treat everyone with mutual respect. Not only this they are open about what they do know and what they don't know. In fact they'll often proclaim I don't know and go about finding out how they can answer your question or solve a particular problem.


A past mentor of mine had a wealth of experience in both the domain and software development itself. In contrast I had no domain experience and very limited practical ability. Despite this gap I was treated as they would treat an equal. No matter how stupid or basic my questions.

However our roles switched one day when I explained about my background in games programming. My mentor decided to have a go, a topic on which he knew nothing. He was both humble and happy to be led and openly admitted his shortcomings. In the end we were able to build a basic game. Here I answered what I considered basic questions, while he gained experience.

Opposite Example

On the other hand some of the worst developers I've worked with are the opposite of the past example.

  • They won't admit they don't know the answer.
  • They won't ask for help.
  • They won't treat others as equals.
  • They won't admit they were wrong.


Software languages, tools and techniques rapidly change. You can't know everything. You can be the expert of one topic one day, and the beginner in another area the next day. Embrace this and learn as you go. Just be humble about it.

  • Admit it when you don't know the answer. Find out if you can.
  • Ask for help.
  • Treat everyone equally, as you would like to be treated yourself.
  • Admit it when you are wrong.

Wednesday, 11 January 2017

Convention Based Tests

Most projects have some form of convention. Examples would include:

  • Attributes/Properties for REST API's
  • Inheritance for third party base types
  • Assemblies/Packages for third party code that is loaded dynamically
  • Folder or namespace conventions
  • And many other forms of conventions

In a few of these examples static analysis can detect issues, but the majority of these problems would resolve only at runtime.

A technique I've used in the past to great success is the concept of convention based tests (CBT). These are tests that ensure a particular convention is followed. As a general practice CBT tend to be written after the discovery of a problem as it is preferable to rely upon higher level tests initially. The good news is that CBT ensure that such problems never return and if a convention is broken you'll be notified during your test run.

In terms of quantity there will be a very small number of these tests, and unlike typical tests that focus on behaviour rather than implementation, these tests are focused on implementation.


Tests generally should favour readability and clarity over the removal of duplication. Additionally the use of programming constructs such as loops or conditionals within tests are usually a bad idea. Using reflection is not recommended in most cases though the opposite is true for CBT.

Reflection allows the previous examples to have tests written in a fairly flexible and dynamic manner. Future changes would automatically be tested.

  • Tests to ensure particular types within a namespace have the correct attribute/property applied.
  • Tests to ensure particular types within a namespace have the correct base class.
  • Tests that assemblies/packages required at runtime are present within the bin directory.
  • Tests that folders/namespaces match a team/project naming standard.
  • And so on.

Simpler Tests

In some cases reflection is not a suitable tool for convention based tools. In this scenarios a simpler style of test is required. These are essentially convention based tests that ensure additional tests are written. These simple tests act more as a prompt to the developer reminding them to add a test for a particular convention.

This test would first detect how many types exist within the namespace and then detect how many tests have been written for those types. While this style of test does nothing other than really count the number of expected conventions versus the number of tests, the failure of this test provides a hint to the developer that they have forgotten something.

The key with these simple detection tests is to provide a good failure message that includes details on why the test failed, and more importantly why and how a new test should be added.

These simple CBT work when the use of reflection is difficult. While they may seem primitive, they do provide value as simple reminders to add future tests. Despite this it's worth remembering they provide no guarantee of the quality of the additional tests that are written. Here peer review is required.


  • Add convention based tests if a convention cannot be detected by static analysis or you cannot detect issues with higher level tests.
  • Reflection is a valid tool to write a single CBT that covers many areas.
  • If a CBT is hard to write, use a test to prompt you to add further tests in the future.

Wednesday, 4 January 2017

Finance For Software Developers

Back at the start of 2016 I set about sorting my personal finances out, inspired by Soft Skills. The book makes a point to consider passive income as a viable solution to wealth building. The reason for this is simple, software developers tend to get paid well if working professionally. Like most professionals though, during school or university you won't be guided on how to handle money until you are thrown into the deep end.

Assets and Liabilities

At the start of February we listed all our assets versus liabilities and were rather shocked. Our net worth (assets minus liabilities) was negative. Not only was it negative, it was negative by a rather large number. This scary realisation forced us down the path of personal finance. Most of this knowledge came from a handful of books and took no more than a few months to really get to grips with the basics. For the small cost of a few books and your time the return on this investment is huge. In summary you want to maximize assets (things that give you income) and reduce or eliminate liabilities (things that take your money away) as much as possible.


Despite knowing nothing than the basics of the stock market and investing, investing in stock (sometimes known as equities) is one of the ways to maximise assets. Again a few simple introductory books and some online research was all that was required. Having explored individual stocks, we settled on low cost index funds as our main investment solution. Before we could invest though we had to attack our debt. Without eliminating the debt we were unable to maximize our investments. Paying off debt is also considered a guaranteed return, something you cannot get with investments, hence it should be your first target.


Attacking debt took up the whole of 2016. Thankfully there was an easy system to follow. The difficult part is sticking the course, though you will quickly start to see benefits. The best solution we found is the debt snowball, which is part of Dave Ramsey's Baby Steps. Steps 1-3 must be completed in order, sequentially. While steps 4, 5 and 6 can be completed in parallel.

Baby Steps

  1. Save £1,000 in an emergency fund.
  2. Pay debts down from smallest to largest using the debt snowball method.
  3. Save 3-6 months of living expenses for a fully-funded emergency fund.
  4. Invest 15% of income into retirement.
  5. Start funding higher education for children.
  6. Pay off the mortgage early!
  7. Build wealth and give!

You Need a Budget

I was actually advised to create a stick to a budget by a friend while in university, however I ignored her wise advice. A budget is a crucial tool to paying off debt and in turn staying out of debt. The best budget to use with the baby steps is a zero based budget. In this case you run your personal finances like you would a company such as a bank. At the end of each month (or whenever you receive income) your balance should be fully allocated to equal zero pounds available. All of your money is either paying of debt or working hard in investments, while the rest is allocated to expenses.

A written monthly budget is single handedly the best piece of personal finance I can recommend to others. Once you tell your money where to go, and have a audit trail of where you are spending you have control. How we lived prior to a monthly budget is a mystery, though it does explain the shocking net worth we amassed. To be blunt, get and use a budget. You need to.


Previously I thought of retirement as something you do when you're old. Think of your parents or grandparents. However this is not the case. Retirement is simply being able to do what you want to do, whether or not this includes work. Being able to wake up each day and do what you want is a powerful thing.

Another shock discovery was the fact that becoming financially independent in order to retire can be done in ten years, instead of the traditional thirty of forty year window. A whole community exists that prove this is the case - FIRE (Financially Independent - Retire Early). To summarise this process, instead of doing what the norm do and investing 10% of your income, invest 50%-90% and you can shorten the process dramatically. FIRE is a long term goal that requires minimized expenses and a strict budget, but the pay off will be more than worth it.


Our personal goals for 2017 include completing our six month emergency fund, followed by aggressively paying off our mortgage, with the goal to complete this within two and half years versus the remaining twenty year window. Without the basic concepts above this would have not been possible.


  • Eliminate all debt, and stay out of debt.
  • Create and use a monthly budget.
  • Use the baby steps to get out of debt and build wealth.
  • Low cost index funds are a recommended way of simple investing.
  • Retirement isn't a thirty or forty year process.
  • No one will teach you personal finance, it's up to yourself to get to grips with it.

Wednesday, 23 November 2016

DDD - Events

The act of something happening is one of the most crucial aspects of implementing Domain Driven Design (DDD). I missed the importance of domain events when first exploring DDD.


Most requirements come in the form when something happens, do this. Something in this case would be an action, and this would be the result taken afterwards. Most domain events can be discovered when requirements use this sort of language.

Another important consideration is that most requirements are evolutionary. They are often added as the feature is developed. What may start off as a single piece of behaviour, may evolve into something much more complex. Events allow this evolution in a decoupled manner.


When a blog post is published, update the authors statistics. In code this may have a signature similar to:

The publish method is responsible for the publishing of the post. This entity holds responsibility for the pre-conditions and post conditions of such action. Also the method takes a domain service that will update the authors statistics as this is not the responsibility of the Post entity itself.

A new requirement may be to automatically send out a tweet with the post title and description. Without events this could be added in a similar manner.

Again the service will do the right thing once invoked, in this case send a tweet out. As you can see we could repeat this sort of enhancement over and over. While this does indeed complete the functionality that the business requires, the solution is far from elegant. A much better solution is to rely upon domain events.


The difference here is the publish method does nothing other than its internal logic. However it does publish (raise) an event to indicate a post has been published. Subscribers (listeners) to this event can then perform their corresponding actions.

Using the previous example two subscribers would be configured to send tweets and update author statistics. Each of these subscribers (handlers) would run in process by default, so their internal implementation should be as simple as possible. In other words record the request, and process this in the background. The code to raise the event is relatively simple, and can simply forward to any registered subscribers based upon a type. Any failure should not cause the publish to fail. Alternatively external subscribers could also handle this event, though this implementation would require the use of resilient and durable storage such as message queues or databases.

Ultimately domain events allow for extremely loosely coupled code, that is open for extension. Each handler can be developed and tested in isolation. The use of composition means that new features should become easy additions, with low risk.

One aspect that may stand out is that the use of this pattern uses a static class to publish events. While in most cases this would be poor for testing, this is not the case here. For tests prior to each step executing you can simply clear any registered handlers and configure what is required. If no handlers are configured, then nothing occurs. Also test handlers that simply report that fact a message has been raised are more than adequate.


While this refactored example is loosely coupled, and open for extension, the intent of what happens after a publish is somewhat lost. Before it was clearer to see what the Publish method would do. This is a trade off, though the pros outweigh the cons here. Most IDE's have a way of showing you the use of all types, so we could easily see any handlers that consume the PostPublishedEvent.

Even with IDE/editor support, the loosely coupled nature of Domain Events can be tricky to debug at runtime. For example I once accidentally configured a game engine to handle events triggered from player movement. This meant that each frame of the game executed the collision detection algorithm twice, instead of once. Without a clear audit of what handlers are being executed upon what events, the use of domain events can be tricky to debug.


  • Domain Events are a key area of DDD.
  • Use events to write loosely coupled code.
  • Ensure you have a method of auditing with handlers respond to which events.

Tuesday, 8 November 2016

POODR Highlights Part 2

Two other stand out topics from POODR were the use of tests and inheritance. The first set of higlights covered dependencies and arguments.


A conclusion that I agree with is that in general most programmers write too many tests.. A great quote in the book sees tests (as) the canary in the coal mine; when the design is bad, testing is hard. Sadly too many poor tests are often written. Examples such as property or construction tests, framework tests or tests that are coupled to the implementation are all common problems. Instead we should aim to get better and more value out of our tests by writing fewer of them, but of higher quality. In short test everything once and only in the proper place. A first step is to simply focus on the ROI that tests give, and focus on the high risk areas.

The test categories are broken down into two core types of tests.

  • Incoming Public Messages (public API)
  • Outgoing Public Messages (To public API of another object)

State based tests should be used for incoming public messages. While verification based tests should be used for outgoing public messages as the state is tested on the receiver, elsewhere. The distinction between commands and queries is also highlighted. In summary incoming messages should be tested for the state they return. Outgoing commands should be tested to ensure they get sent. Outgoing query messages should not be tested, merely stubbed.

These testing rules are nothing new, but the summary and importance of following these guidelines is nicely summarized within the chapter covering testing principles.


Inheritance is widely abused and misunderstood. Either inheritance is the solution for all problems, or you're advised to never use inheritance. POODR takes a more pragmatic approach. Inheritance is a tool that can sometimes provide an excellent solution, however you are better off duplicating code and defer such decisions until you know more.

The wrong abstraction is harder to work with than duplicated code as duplication can easily be removed. A bad abstraction that is used in many places is much harder however. The application of the Rule of Three can help here.


  • Tests are hard - write less but focus on the quality.
  • Minimize the number of tests you write by using boundaries via incoming/outgoing messages.
  • Inheritance is not all bad.
  • Defer or hold back using inheritance until you understand the problem.