Yes, totally agree with this-- I perhaps should have emphasized that my point is to code the shortest path thru the hardest problem. If somehow you just code around the hard part & keep deferring that til later you haven't learned anything.
Hi! Yes I couldn't find a better source, here's excerpting from the book--
"We once undertook a complex client-server database marketing project. Part of its requirement was the ability to specify and execute temporal queries. The servers were a range of relational and specialized databases. The client GUI, written in Object Pascal, used a set of C libraries to provide an interface to the servers. The user's query was stored on the server in a Lisp-like notation before being converted to optimized SQL just prior to execution. There were many unknowns and many different environments, and no one was too sure how the GUI should behave. This was a great opportunity to use tracer code. We developed the framework for the front end, libraries for representing the queries, and a structure for converting a stored query into a database-specific query. Then we put it all together and checked that it worked. For that initial build, all we could do was submit a query that listed all the rows in a table, but it proved that the UI could talk to the libraries, the libraries could serialize and unserialize a query, and the server could generate SQL from the result. Over the following months we gradually fleshed out this basic structure, adding new functionality by augmenting each component of the tracer code in parallel. When the UI added a new query type, the library grew and the SQL generation was made more sophisticated. Tracer code is not disposable: you write it for keeps. It contains all the error checking, structuring, documentation, and self-checking that any piece of production code has. It simply is not fully functional. However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary. Once you're on target, adding functionality is easy."
They later list some of the advantages of this approach--
- Users get to see something working early
- Developers build a structure to work in.
And differentiate it from prototyping--
"The tracer code approach addresses a different problem. You need to know how the application as a whole hangs together. You want to show your users how the interactions will work in practice, and you want to give your developers an architectural skeleton on which to hang code. In this case, you might construct a tracer consisting of a trivial implementation of the container packing algorithm (maybe something like first-come, first-served) and a simple but working user interface. Once you have all the components in the application plumbed together, you have a framework to show your users and your developers. Over time, you add to this framework with new functionality, completing stubbed routines. But the framework stays intact, and you know the system will continue to behave the way it did when your first tracer code was completed."
It's still a great book 20 years later, I highly recommend picking up a copy.
Yeah 100%. I'm not suggesting land technical debt, it's more about the approach to solving the problem in the early stages while you're still seeking a solution-- don't get bogged down by perfectly conforming to a bunch of intermediary abstractions on your way towards the goal.
Great feedback re the risks of physical metaphors! I'd agree a bad one does more harm than good. Lakoff points out that our linguistic conceptions typically compose-- so you can talk about both IDEAS as BUILDINGS and as CONTAINERS because the former is a special case of the latter-- and we lose that quickly when mapping to programming. I'm not sure if that's inherent in how abstract these things are or if it just hasn't been attempted on a deep enough level. (Do other control structures fit into the railway paradigm? Is it generative?)
Enjoyed your post, lots to unpack in the 'cleanliness' analogy, will think on it.