I've been gestating three different books in my head for a while. You would expect that having three books in your head is great for productivity, but it seems that the opposite is true. It's hard to decide which one to work on, so I get vapor-locked by indecision and work on none.
With a deep sigh, it's time for me to admit that none of these is going to emerge like Athena, fully-formed, from my head. To my chagrin, it looks like I actually need to sit down and do the work of writing one of them. But which one?
In the spirit of garnering feedback early and often, I'd like your input. Leave a comment, please. Which, if any, of these three books would you most want to read?
Blueprint for a Web Company
A cross between Chasing the Rabbit and The Art of Scalability. The best companies today know how to bring together a handful of ideas across several dimensions. Each of these ideas gives an individual a bigger lever to impact the company. Instead of focusing on risk avoidance, these companies make many survivable bets.
This book would show how to combine:
- Product-oriented organizational structure
- Data-driven decision making
- Decoupled software architecture
- Cloud computing and cloud-native application architecture
- Lean software development
Doing any of these things will deliver benefits. Do them all, and it's like a turbo boost for your company.
This would be a full-length book.
The Hickey/Halloway Paradigm
Clojure and Datomic express a distinct set of ideas about software design. Rich Hickey and Stu Halloway have articulated these in various presentations. As we have worked with Clojure, Datomic, and ClojureScript, and as we have built Pedestal, many of us at Relevance have adopted this paradigm for programming.
This book would articulate the principles of this style: an explicit approach to time and context, the separation of identity from state, what makes a good abstraction, and how to structure real-world systems from functional, explicit, evident components.
This would be a medium-length ebook.
The Truth About Data
E.W. Dijkstra famously said "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." I would make a similar case about relational database structures. We get such early training in normalization, entities, and relations that we are tempted to think of these as the "natural" form of data. Absolutely not.
Normalized databases as we practice them are not essential to the relational model, and the relational model itself is an arbitrary set of constraints applied to a much richer fundamental view of data.
In "Data and Reality," William Kent described many ways in which our models are arbitrary. "Arbitrary" not in the sense of capricious, but in the sense of representing choices from a set of potential models with equal validity.
There is another way to understand data. We can apply some very general abstractions to apprehend a data set as a kind of Platonic ideal, from which we project our actual data sets. In this view, entire databases look like points in a many-dimensional space and data models are just projections of this space into reified memory, storage, and index structures. Queries are further projections. Transactions move the database from one point in this space to another.
This would be a medium-length ebook, and may be a bit challenging.
Need Your Voice
Please leave a comment below. Which of these, if any, sounds interesting to you?