Recent Reads, Recent Thoughts

It's been a good end-of-year/start-of-year. I don't know if I'll ever "work" again, or have to, but I'm getting ready anyway. A guy has to do something with his time. I put that dangerous word "work" in quotes because "work-for-money" is definitely a different beast from "work-for-gain". They aren’t the same. I'm going with Plan B for Max Gain.

Being paid isn't necessarily a "gain", either. It's just money. Money is handy to have, and useful for many things but not for all things. Mostly I'm interested in becoming better, as in sharpening my thinking, improving my ability to understand, and being able to reliably tell which from what.

So, in keeping with the title of this post, here are my recent technical reads.

(1) "Ship It!: A Practical Guide To Successful Software Projects", by Jared R. Richardson, 2005. Unfortunately, there will never be an update since the author died in 2016, but it's still a great book, even after two more decades.

(2) "The Pragmatic Programmer, Your journey to mastery", 20th Anniversary Edition by Dave Thomas and Andy Hunt, 2020. New, fresh, even better than the original, which I re-read about two years ago.

(3) "Extreme Programming Explained: Embrace Change", by Kent Beck, 2005.

(4) Basecamp/3ySignals books...

• "Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application", by Jason Fried and David Heinemeier Hansson, 2006.
• "Rework", by Jason Fried and David Heinemeier Hansson, 2010.
• "Remote: Office Not Required", by Jason Fried and David Heinemeier Hansson, 2013.
• "It Doesn't Have to Be Crazy at Work", by Jason Fried and David Heinemeier Hansson, 2018.
• "Shape Up", by Ryan Singer, 2019

I was hoping to find a newer edition of the extreme programming book, but no. Too bad. It's surprisingly great, and reading it left me wondering what Kent Beck has rethought in the last 19 years. I guess he done wrote it all out the first time. Pretty good as-is anyway.

So — There are lots of things to chew on presented in these books, but mostly they boil down to paying attention, working together, and using the best available tools and processes to best advantage. And these days there are lots more tools, more-capable tools than there were 20 years back when I had to smile and keep eating shit, if I wanted to keep my job. And pound my head against the wall just to get some relief.

If I may over-summarize what I got from the above books, collectively:

• Get some input.
• Use that to create a working system right now.
• Put everything into version control.
• Create tests and run them constantly.
• Integrate constantly.
• Maintain a working system from day one.
• Be transparent.
• Review, collaborate, compare, rethink, revise, redo, repeat.

Some ideas, not all of them new, from the above authors, and from some other research I've done lately:

• BDD: Behavior Driven Development
• CD: Continuous Delivery
• CI: Continuous Integration
• CIT: Continuous Integration Testing
• DbC: Design by Contract
• DTD: Design Top Down
• ESA: Environment Setup Automation
• FBoxing: Feature-Boxing, aimed at getting specific features done
• FDD + WBS: Feature Driven Development + Work Breakdown Structure
• Jugaad: Humility, Openness, Frugality
• Linting: Random input stress testing
• Preemption: If it isn't going, kill it
• TBD: Tracer Bullet Development
• TBoxing: Time-Boxing
• TDD: Test Driven Development
• Value: Do the most important thing first

I hereby recommend all of these books, and all of the topics in the list directly above.

Yeah, so fun. It looks like fun, if I'm up to it. I have enough topics to keep me busy for as long as I can keep my eyes open and my heart beating.

Besides that, I'm now reading "Poor Charlie's Almanack" ("Poor Charlie's Almanack: The Wit and Wisdom of Charles T. Munger" edited by Peter D. Kaufman, 2005.) Until just a few months ago, when he himself stopped breathing, Munger was Warren Buffett's longtime partner in Berkshire Hathaway. They did well. Together, and even separately. They knew lots.

This book contains my final kick in the butt, the push past the tipping point, the item that suddenly allowed me to consolidate all of my new thoughts.

Munger mentions the "Five Ws" (five dubble-youse): Who, What, Why, Where, When. And I now throw in a "How". I don't recall the context of Munger's use of these, but the concept has been around at least since ancient Greek philosophers began anciently, greekly, philosophizing. And it's been used, with a "How" added on, in journalism too, also from pretty far back.

Anyway, it came to me in a flash of at least reasonably bright illumination, considering the amount of intelligence that I'm capable of bringing to a subject, that this is the whole of software development, and a lot of other problem solving and engineering approaches as well: Who, What, Why, Where, When, and also How.

The "w" items set the stage. They're the user stories, the problem statements, the business rationale, the requirements, the documentation, the contracts, the law, and all that. They set the stage. And the "How" is the code that comes trotting along behind to make it all dance.

For a whole long time now I've been amazed that developers keep going on about just churning out code, "self-documenting" code even, as if that was even a thing, while completely ignoring the whole core of the issue. Code says "How", but the important parts, the central issues, are "What" and "Why". What the hell are we doing here and why in the hell are we bothering? How is actually pretty easy, even its hard parts. As a former co-worker of mine used to say "I can teach a chicken how to code. The important part is keeping the big picture in mind and solving the right problems."

The last job I had before giving up was in a completely dysfunctional state agency. (Go figure.) I was hired to work on a project rewriting a mainframe system as a client-server system. As usual, one of the first things that happened was that all the work went to contractors, and then it got worse from there, before it got worse, and then kept getting worse.

Back then, "UML" (Unified Modeling Language) and "RUP" (Rational Unified process) were state of the art, big-time practices as was hiring a person to sit at a computer and do manual testing, all day, every day, forever. But we didn't even do much along those lines, beyond management saying that we were doing it all. So things have come a long way. People actually follow actual processes now. Verifiable processes.

Even Kent Beck, with his 2005 book on XP (Extreme programming) was about 16 decades ahead of where we were, even though I quit that place in 2003, before the book, before "Agile" and "XP" even became common, though well after their principles had come into use here and there.

But I think I've got it now. After it's too late for my so-called career, of course, but my aim is understanding, rather than hoping for a someday promotion from Information Technology Applications Specialist 4 to Information Technology Applications Specialist 5 so I can qualify for higher retirement pay and just get the hell out.

It's not a competition between hotshot coders who say code is everything and documentation is unprofessional and a horde of buzzing bureaucrats intent on filling shelves with neatly-bound volumes that no one ever reads or can understand, documenting a system that was never actually built that way anyhow, but a cooperation of all involved, fully and completely understanding "Who", "What", "Why", "When", and "Where", as implemented by a working and fully functional, ever-improving "How". To get things done.

Yeah, so thanks, Charlie. I needed that. Decent kick in the ass. I'll keep these ideas in mind, whatever it is I happen to be doing from now on.

Now I need to get back at it, just for my own satisfaction and personal edification, maybe by starting with learning Go. We'll see. Maybe I still have enough time left to do something useful with my life.

 

---

Have anything worth adding? Then try sosayseff@nullabigmail.com
Me? As noted above, but maybe a little crazier.

 

Etc...

so says eff: sporadic spurts of grade eff distraction
definitions: outdoor terms
fiyh: dave's little guide to ultralight backpacking stoves
boyb: dave's little guide to backpacks
snorpy bits: nibbling away at your sanity
last seen receding: missives from a certain mobile homer
noseyjoe: purposefully poking my proboscis into technicals

Who Me? Yes.

See "How To Live Like A Cynic" by Ansgar Allen, December 6, 2023 at psyche.co ( https://psyche.co/guides/how-to-live-like-a-cynic-and-challenge-social-norms OR https://web.archive.org/web/20231207101328/https://psyche.co/guides/how-to-live-like-a-cynic-and-challenge-social-norms )

For a while I thought this was it. Not quite, but it's close. It's inspiration.

I keep thinking that if I had my life to do over again, everything would be different. True. True of me an everyone else, but how? Definitely more along these lines:

• Improvise your life.
• Live shamelessly.
• Push against all boundaries.
• Act with courage, refuse to respect the powerful.
• Give up everything you can live without.

I also recommend "Mornings on Horseback" by David McCullough, an amazing and thorough book-length biography of Theodore Roosevelt. He lived somewhat along the lines of the principles listed above, better than I have, though much more conventionally than Diogenes. Everyone has lived much more conventionally than Diogenes, but it's the core ideas. Very similar in both cases. Both fearless beings.

Particularly, in my case, I come from people who try to fade into the background, and had almost no education in how to get through life from my parents. They were both clueless, both the youngest of large families, my mother being a good little girl and my father being a spoiled brat who never worked. Both incapable of actually dealing with what life threw at them.

Being shy, and bookish, and having no clue about anything, and seeing my relatives wander aimlessly through their own lives, I grew up making lots of mistakes. Mostly mistakes. All the way through. My whole life so far has been one continuous mistake.

I have missed nearly every opportunity, played by the rules, deferred to authority, hoped for the best, and continued getting it all wrong.

Now I'm revamping myself, reinventing, reforming, redoing. Though I no longer have to work for money, I am working, working at making myself the person I should have been all the way through. My one practical talent is that I know how to live within my means and with that have always been good at saving money, so I've got enough of that anyway, and its freedom.

I read Allen's "How To Live Like A Cynic" piece, and then got his book and a couple others on cynic philosophy and started reading them. And quickly gave up on all. Three academic works, going into endless detail about everything except the subject that I was interested in. The bullet points above do a better job, and Allen's piece is stellar. He hits the relevant points and covers them in enough detail to get the core ideas across. That's enough right there. You don't need more.

I'm thinking a lot here of software development, but I'm actually more interested in process than in programming, though in my so-called "professional" life, producing software was supposedly the goal. In line with this, I'm also working my way through Andy Hunt's "Pragmatic Thinking and Learning: Refactor Your Wetware", which is all about thinking. Also great. Ground-breaking, earth-shaking. More than reformative. Revolutionary.

For me it's all about the principles. I'm abstract, more interested in "what" and "why" than in "how". Cynicism and pragmatic thinking have been key parts of me since the beginning, and I'm only now, late in life, realizing that, and identifying who I could have been and what I could have done. I'm an inventor, a designer, a creative, iconoclastic dirty-fingernail philosopher. For me, what works is what works, and I keep trying to figure that out, no matter how anyone else does it. ("If it ain't broke, don't fix it," and "We've never done it that way" have always enraged me, and will forever.)

OK-fine and too bad. My life has been a waste, but here we are.

At least I do recognize the truth of things and am working on it. I like clarity and direction, unencumbered by the clutter of life, so once again:

• Improvise your life.
• Live shamelessly.
• Push against all boundaries.
• Act with courage, refuse to respect the powerful.
• Give up everything you can live without.

These are things that I've been doing all along, but accidentally, too quietly, in private, internally, without a real plan.

I'm not now headed for the street to run up and down, howling, and knocking the hats off people to get my point across. No. I plan on asserting myself when necessary, standing my intellectual ground, never being intimidated, living bullshit-free, and just getting on with it. Anyone else wants to do it a different way, fine, go ahead. Not me. I won't get in your face unless you force it.

It's December, the Xmas season, again. When I was five years old I badgered my parents until they finally gave in and admitted that Santa Claus was a fake, didn't exist. That's me. I'm proud.

And that was about five years before we had television. Before we had television, so I wasn't seeing programs every night with plots about guys dressing up in funny red suits to lie to children. How I figured it out I don't remember, but I did. Santa Claus is the first deep societal evil perpetrated on children.

I got past that and want to live the remainder of my life getting past the rest. End of story.

 

---

Have anything worth adding? Then try sosayseff@nullabigmail.com
Me? As above.

 

Etc...

so says eff: sporadic spurts of grade eff distraction
definitions: outdoor terms
fiyh: dave's little guide to ultralight backpacking stoves
boyb: dave's little guide to backpacks
snorpy bits: nibbling away at your sanity
last seen receding: missives from a certain mobile homer
noseyjoe: purposefully poking my proboscis into technicals

As If It Mattered

This can't be a new idea, but it is new to me, and I doubt that very many people have paid enough attention to the problems of software to have thought it through well enough.

Estimation. How long will it take? When can I have it? Why isn't it done yet? Perennial issues. I know — writing software isn't the same as building a bridge. Writing software isn't building anything. Writing software is imagining something.

The building part is hitting a key or two and generating another copy of the runnable software, but the writing of it is not equivalent to construction. The writing of software is equivalent to one part of the planning and design process. Equivalent to one of the last stages of that, but still not the same as piling bricks on top of each other.

And yet, especially with what is called "agile" software development, or more often these days, what has been congealed into "Agile", the process depends on starting by asking naive users of an existing system, or equally naive future users of a system not yet built, what such system should do: Getting "user stories".

Does anyone suppose that this might be a way to build a nuclear submarine? A power grid? Would anyone ask a few random commuters how a new highway bridge should be built? No? Then why ask "users" what a software system should be like?

It seems to me that any business that needs a software system should put muscle into the process, should get serious, should actually commit. Experts should come in on the first day and really seriously hash out in detail what the laws are, what the business requires, how things are done now and how things need to be done once the new software is in place, and skip the story nonsense.

User stories be damned. Get serious already.

Sure, lots of big material projects go sideways all the time, but no one starts building a bridge across a river and ends up with a barrel factory. Because people are committed to getting it right. Things get sloppy when people do, not because things are inherently sloppy and completely unpredictable. Pay attention, work closely together, and don't let anything happen without it receiving close and continual scrutiny.

Run this sort of system a couple of times and you have a factory that can generate solid, clean, working software, and if you need estimates, then good ones ought to come along as an inevitable part of the process.

Can't be that hard, not if anyone really cares enough to treat development as if if mattered.

 

---

Have anything worth adding? Then try sosayseff@nullabigmail.com
Me? Haven't quit thinking yet.

 

Etc...

so says eff: sporadic spurts of grade eff distraction
definitions: outdoor terms
fiyh: dave's little guide to ultralight backpacking stoves
boyb: dave's little guide to backpacks
snorpy bits: nibbling away at your sanity
last seen receding: missives from a certain mobile homer
noseyjoe: purposefully poking my proboscis into technicals

Why

So I just finished reading all the books put out by Basecamp/37Signals: "Getting Real", "Rework", "Remote", "It Doesn't Have To Be Crazy At Work", and "Shape Up".

They have a process. It works. It works for them. Beautiful. I learned lots.

And I have been wondering how this might have worked in the world that I formerly inhabited.

Basecamp/37Signals (whichever name the organization has finally settled on these days) has for a long while been a smallish private outfit that sold a few different pieces of software. Mostly that was just one: "Basecamp", a project management system developed in-house and made into their only product.

A couple of years ago they then created "Hey", an email system, so they have two products now.

Me, I worked most of my so-called career in state government. Luckily I escaped with my life but though heavily scarred I am still interested in process, and I have been wondering how the Basecamp approach might work for systems that are still back in the age of stoneheads.

Government work, at best, is severely constrained by laws. Supposed to be, but it's sloppy. But it's supposed to be based on law, so let's go with that. That's one thing.

Another is effectiveness, or not.

There is "10 Principles of Effective Organizations" by Michael O'Malley, as published by the Harvard Business Review.

The principles as defined by that are:

 1. Encourage cooperation.
 2. Organize for change.
 3. Anticipate the future.
 4. Remain flexible.
 5. Create distinctive spaces.
 6. Diversify your workforce - and create an inclusive environment.
 7. Promote personal growth.
 8. Empower people.
 9. Reward high performers.
10. Foster a leadership culture.

Nope. Not where I worked.

Where I worked, the watchword was "wait", and none of the above items applied, or were even known. If "wait" wasn't emphatic enough, then there was "If it ain't broke, don't fix it." That worked too.

An as an extreme edge case, anyone especially daring might have added "Ask your supervisor." But you could never tell how things might turn out if you made a target of yourself, so quiet waiting was always the best plan.

Then there is the "Capability Maturity Model" as another gauge of effectiveness.

Its levels are:

1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process.

2. Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted.

3. Defined - the process is defined/confirmed as a standard business process.

4. Capable - the process is quantitatively managed in accordance with agreed-upon metrics.

5. Efficient - process management includes deliberate process optimization/improvement.

Nope. Again.

There was none of that either. Even level 1. We were never that organized, anywhere I worked, especially the "individual heroics" part, because you were either supposed to ask your supervisor, which could be dangerous (The nail that sticks up soon sees a hammer.), or better yet, "wait". No matter what, something always happened eventually, so waiting was terrific.

Anyway, at Basecamp/37Signals, according to what they've published, they usually let things ride until they see a genuine need to alter/extend/improve their product.

Once there is a clear need, they assign a small team to "shape" a problem/solution set, coming up with a general direction for a design and a general set of requirements. After that, upper management picks what looks most promising (what they call a "bet"), and they go into a six-week development cycle. At the end of that, they either have a finished project or something that they need to abandon, at least for the foreseeable future. Then they spend two weeks cooling down, cleaning up, and ramping up for a new cycle.

What I don't get is how they start on a completely new product. You can't pick a part of that to improve, or a part to add, since there isn't anything there to improve or add to, but they don't cover that part in any of their books.

And since the business is both private and privately held, they don't have the dozens or even hundreds of legal requirements that a state government agency would have, not to mention perennial funding issues.

But it seems to me that one huge problem in government work is that basically no one cares. Some people do, but they're either demoted or fired, or maybe just defined as crazy and ignored. The real problem where I worked, as I see it, is that the legislature would meet, pass a bunch of laws, and then the legislators would all go home again.

The next phase involved the governor turning around and passing the new requirements to all the state agency heads, and going back to posturing and planning for the next election.

The heads of the state agencies would take the directives they got, hand them off in turn to their deputies, and return to posturing and playing politics, and maybe planning their own run for governor.

The rest was a continued cascade of delegation and dilution of responsibility until the directives became so feeble and confused that no one knew anything specific any more, so they waited, listening for any howling and/or bellowing from on high. At that point someone might get to work, but reluctantly and very slowly, because you can never do the wrong thing if you don't do anything, and you can be punished only for doing the wrong thing, which can't happen unless you actually do something. So there.

And a lot of people were just plain incompetent. The branch of the last state agency that I worked for had a head of IT who got the job because she was a friend of the head of that branch and would qualify for higher retirement pay when she retired from that position in a couple of years. At the time of her appointment, she had never used a computer, and though she then got a desktop computer, she didn't even know how to turn it on. Head of IT. True. I was there.

Yes, I'm glad that I finally quit. At least I got that part right.

And another thing.

I've also been thinking about a short conversation I had with a barely post-highschool guy a couple of decades back. He was apparently a real hotshot with MySpace. Could do anything that it was possible to do there. Had a lot of followers. Lived to code. Got angry when I suggested that he should also work feverishly and relentlessly on his communications skills, never forgetting the spell-checker. All as a real leg-up on any competition.

I was trying to helpfully pass on a tip, but he took it personally, like I was his prissy seventh-grade English teacher trying to scold him with a personal putdown, correcting him when he said "cootnt" instead of "coodent" when pronouncing the word "couldn't", or something like that.

But you can't really talk to people who know it all, until they eventually learn the hard way. (MySpace experts — where are they now?)

So it occurs to me that the essence of getting anything done, formal process or not, especially with software, is covered by three principal ideas:

1. WHAT
2. WHY
3. HOW

The "HOW" part is coding, what the code monkeys and high-testosterone highschool boys think is important.

If my conversation with the young hotshot had been in 1967 instead of 2007, he would have been aiming at a career in either auto-body repair or auto mechanics, and he would have been completely unimpressed by anything else, because of his Mad Buffing Skillz, with which he would soon dominate the world.

Instead, he knew the computer programming equivalent of highschool auto body repair and knew deep in his heart that he was legend, and that masses would soon bow down.

As a former co-worker of mine said, when he became ranked high enough at work to be on hiring teams, he could teach a chicken to code, any chicken, but the important part was being smart, being able to identify problems and think through them. I.e., knowing how to focus on the actual business issues.

"WHAT" is also important, more important than "HOW". The "HOW" part really doesn't matter that much. If it did, then we wouldn't have so many programming languages. Maybe just one. Just one that made all things happen. But there are whole batches of them all over the place, and new ones every week, so if there are hundreds of ways to do "HOW", then "HOW" really ain't that significant.

So the summary judgment on "HOW"? Right behind "WHAT", but way back. Meh.

The crux is "WHY". Why do something, after all? What you do and how you do it come way later. It's the "WHY" part that drives everything. Why this, why that, why not the other, and so on. Without a good "WHY", it's best not to even start.

This is the part that Basecamp/37Signals gets right, and none of my work life did.

They work to improve what they've got, when there is a good business case for it, and they improve what they've got when they realize that a particular improvement is more relevant than anything else.

Simple, direct, effective. Versus endless confused thrashing.

True, Basecamp/37Signals is still private business, privately held, and the whole deal would work a bunch less well in big businesses, let alone the creaking, dark dungeons of government, but me, I'm free now, haven't had to work in years, and am now able to explore the real meaning of excellence and fantasize about the life that could have been.

At least there are some who live glorious, rational lives, knowing which is in a way nearly as nice as if I had been able to do that, so there is that then, and I salute them no matter what.

 

Refs:
Effective Organizations
Effective Organizations, alt link
Capability Maturity Model
Capability Maturity Model alt link
Books by Basecamp

 

---

Have anything worth adding? Then try sosayseff@nullabigmail.com
Me? Slow learner.

 

Etc...

so says eff: sporadic spurts of grade eff distraction
definitions: outdoor terms
fiyh: dave's little guide to ultralight backpacking stoves
boyb: dave's little guide to backpacks
snorpy bits: nibbling away at your sanity
last seen receding: missives from a certain mobile homer
noseyjoe: purposefully poking my proboscis into technicals