Skip to main content

Posts

Logging vs Auditing

The difference between logging and auditing is a subtle yet important distinction.LoggingTechnical in nature. Deals with technical concerns, stacktraces or errors.Additional levels such as DEBUG, INFO, WARN, ERROR, FATAL for classification.Logging can be simple such as traditional stdout statements, or more complex with semantic/structured logging.Should not cause a runtime failure if logging is defective, fail silently.System should work with or without logging enabled from both a technical and system view.No need for automated testing, simply ensure this works afterwards. No need for interfaces or abstractions, use the logging library directly.The primary users of logging should be the development team when developing and testing. Additional the team should use logging for daily monitoring and support. Effective log monitoring can produce trends or highlight problem areas well before users report them as issues. The use of a good monitoring system can also remove and reduce the need…

The QA Test Matrix

Historically teams I've worked with have taken a few varying approaches when designing tests against acceptance criteria. One is to have the business define the feature, while the team help define the acceptance criteria. Ultimately the business gets the final say if they agree, and further acceptance criteria is either added or removed. The strength of this approach is everyone is involved with the process so nothing is missed or misunderstood. The biggest flaw with this style is that the documentation produced is often verbose, using wordy Given-When-Then scenarios. Using this plan a test plan is then created, mapping tests to acceptance criteria.An alternative approach is have the business define both the feature and acceptance criteria while the team come up with a corresponding test strategy. This more technical approach allows for a separation of testing activities and test categories. Finally the test plan is replayed back to the business and correlated against acceptance c…

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.ExampleA 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 ExampleOn the other hand some of the worst deve…

Convention Based Tests

Most projects have some form of convention. Examples would include:Attributes/Properties for REST API'sInheritance for third party base typesAssemblies/Packages for third party code that is loaded dynamicallyFolder or namespace conventionsAnd many other forms of conventionsIn 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…

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 LiabilitiesAt 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 (thin…

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.WhyMost 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.ExampleWhen 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 servic…

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.TestsA 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 inc…