#devpractices
39 posts

The Myth of Advanced TDD

This is an excellent post around using tests to drive design decisions. TDD is a much touted, much hated and much loved paradigm in the software world.
Read more

The Myth of Advanced TDD

This is an excellent post around using tests to drive design decisions. TDD is a much touted, much hated and much loved paradigm in the software world. This post shows how using mock objects in a test case allows us to expose design flaws in our codebase.

  • Listen to the test cases to refactor and improve your code design.
  • Mock objects and test doubles expose design risks early. If the code seems very tightly coupled to the test case, then change the design.
  • If the test has duplicate assertions for the same field, that points to a missing abstraction.
  • In your code flow if a lot of code seems inter-connected, consider using event sourcing to reduce the coupling. It'll make the tests also easier to write.
  • Advanced TDD is indifferentiable from diligent TDD.

I've been trying to incorporate more TDD in my professional projects. This post was the trigger to be more conscious and diligent about it. Do you practise TDD in your daily flow? Any other resources I should read on this topic to get better?

Full Post here, 13 mins read

Manage technical debt: How to shine a light on issues in your code base

This post likens accumulating technical debt to financial debt. There are nuances to this metaphor but it helps us visualize and understand technical debt.
Read more

Manage technical debt: How to shine a light on issues in your code base

This post likens accumulating technical debt to financial debt. There are nuances to this metaphor but it helps us visualize and understand technical debt.

  • Technical debt is accrued because of the changing nature of software products. Since software is a virtual system, most users don't know what they want till they see an initial version. After that point, modifying the codebase is like building a skyscaper on the foundations of a 2 storey-house.
  • Symptoms of technical debt include: bugs, performance or quality issues, speed of feature delivery, burnout in the team. Keeping an eye out for these symptoms helps us bring the issue to the forefront.
  • One suggested way to reduce technical debt is to keep swinging between feature addition and software improvement. This ensures that the software always has some breathing room for growth.
  • Notice the symptoms and allow the engineering team to front-load the cost of fixing the issue. For example, if the ops team is awake most nights, instead of adding a new feature, work towards fixing the root cause of their nightmare. This builds a culture of quality-first.
  • Technical debt is everyone’s problem, and once you surface the issues, fixing them is far easier.

Full post here. 7 mins read

The Pyramid of Unit Testing Benefits

Effective unit test coverage on your codebase is the holy grail of software development. While it takes effort to do, at times the benefits aren’t entirely clear. This article details the benefits of unit testing very effectively.
Read more

The Pyramid of Unit Testing Benefits

Effective unit test coverage on your codebase is the holy grail of software development. While it takes effort to do, at times the benefits aren’t entirely clear. This article details the benefits of unit testing very effectively.

  • Validates your code by giving you immediate feedback. Silly mistakes and bugs can be caught early through this process.
  • Forcing your code to be testable generally leads to better design and explicit dependencies.
  • You can use the test suite as an up-to-date documentation of the software. If the tests pass, that’s what the code is supposed to do.
  • Prevent regressions by building an extensive test suite.
  • We are all constantly refactoring our code. Having a good test suite acts as a good safety net to ensure that we still deliver the functionality that was promised.

Full post here, 3 mins read

Lessons Learned while Working on Large-Scale Server Software

Working on large scale software comes with its own unique set of challenges. Here’s a set of tips to remember when faced with a mammoth challenge. While the entire article is a longer and better read; here are some distilled points.
Read more

Lessons Learned while Working on Large-Scale Server Software

Working on large scale software comes with its own unique set of challenges. Here’s a set of tips to remember when faced with a mammoth challenge. While the entire article is a longer and better read; here are some distilled points.

  • Plan for the worst. Creating a baseline for the worst thing that can happen is comforting. It also helps us plan for failure (because failure is inevitable).
  • Don’t trust the network. We often take the network for granted. But network latency and flakiness can be a source of immense pain because your production system behaviour doesn’t match your localhost.
  • Crash-first software. Big, loud crashes bring a developers attention to the problem faster, thereby helping them fix the bug. Silent failures fester in systems far longer and crop up at the most inopportune moments.
  • People are the lynchpin of any system. A lot of success of large scale software depends on how people react to failure. This problem is magnified when a senior engineer leaves the team or new members join the team. Default to using tools and  processes to ensure that tribal knowledge is codified and persistent.

Full post here, 11 mins read

Production Oriented Development

This is a great article from a battle tested veteran. Lot's of sane advice, some controversial ones and some nuanced ones.
Read more

Production Oriented Development

This is a great article from a battle tested veteran. Lot's of sane advice and some, some controversial ones, some nuanced ones.

  • Engineers should be on-call and operate their own code. They know where the skeletons are hidden. Also, experiencing the pain of production failure is the quickest way of fixing them.
  • Buy beats Build. NIH (Not Invented Here) syndrome is very strong amongst tech teams but it's generally a recipe for disaster. Use SaaS tools, managed-code tools or hosted services to reduce the burden on yourself and your team.
  • Make deploys easy. The easier a process, the more it's followed. Deploy pipelines should be simple, quick and pain-free. Frequent deploys have a lot of advantages. Your customers receive value faster, the changes are smaller and it's easier to debug.
  • QA teams slow everyone down. This is a highly controversial statement and has a lot more nuance. Manual QA cannot keep up with release cycles. Aim to automate
    as much testing as possible. Also, move QA teams to testing in production to ensure business continuity rather than being road blocks.
  • Be boring! Boring technology is battle tested and bug free. Always bias towards using an old, boring technology instead of bleeding edge frameworks.
  • Things will always break. Planning for failure response is a more scalable strategy rather than prevention of failure. The former leads to better systems, while the latter leads to failure. I personally connect to this advice. We can't plan future incidents, but we can plan our response to them.

Full post here, 11 min read