Choosing the right amount of process is an art. Too much process is smothering and too little is a mess. However, I think incremental, stable, and additive processes naturally start simple and mature progressively with our demands.
“No ideal process, or set of processes, exists” “Software processes must be selected, adapted, and applied as appropriate for each project and each organizational context.” (SWEBOK Ch 1.1 intro). No one likes to hear “that’s just how we do it”. Process without understanding leads to frustrating lack of results. Understanding factors of good process is critical for effective work across projects and for continued improvement. My working hypothesis is that effective processes are incremental, stable, and additive.
Code is not the goal of programming. Programming is about understanding and representing problems. While this belief is expressed by many experts, the repercussions are many and nuanced. This is my latest attempt to communicate the idea clearly.
I finally got around to reading Getting to Yes, which several friends have recommended. It is a fantastic crash course in negotiation. I also couldn’t help but notice the similarities between negotiation and design.
I want to directly address the idea that moving quickly means bad code. Heavy design process is also not the opposite of either speed or sloppy code. To go fast is to go well, and that means fast incremental design.
The Cycles of TDD by Robert Martin is the most wholistic explanation of TDD I’ve read. It helped me to put the pieces together and understand how TDD can drive a good design process from end-to-end. Here’s an attempt to visualize it.
I once worked for a company that exposed all of their entities IDs as integers. It’s common practice, but it bit them hard when they needed to adopt an offline-then-merge strategy for client data. This required switching ids to Guids all over the code base and it was an arduous undertaking. I’ve been trying and failing to simply abstract ID types since.
I want to cleanly represent predictable failure states as part of my function contracts. This lets consumers know right away what scenarios they should expect without documentation or looking through code. F# encourages this pattern and normalizes it with the Result type. Representing the same idea in C#, however, is non-trivial.
Sometimes a constructor or function can naturally accept multiple types. The classic solution to this is overloading. The problem is overloading can combinatorially expand for every multi-typed parameter.
Aspect-Oriented programming has captivated my imagination for years. C#, however, does not support AOP. Even conceptually realizing benefits of the paradigm proved difficult. Then, I experienced functional composition.