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

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

So Now I'm A Borgler

Borg. I did it.

I'm not sure why, but I guess I had to try.

I had and still have a good data backup system that I created on my own. I have had to restore whole directories from it, and it works. I trust it, but of course it isn't perfect.

The system that I wrote is slow and also redundant. In a way, those characteristics are positive, slow less so, but I can live with slow if that's what it takes to do it right.

Redundancy means safety. Because with redundancy I know that I have multiple copies of irreplaceable data, saved daily. I have the space to store multiple copies of my data, so the only real issue with my in-house data backup system is that writing four to five GB of data to external drives takes a bit of time, and I have been doing it twice a day.

But then I read about other ways to do this sort of thing, and there are several well-known systems, Borg probably being the best-known, so I just got a bit itchy to try something, and started with Borg because it looked like the most complete system and the one with the longest and best track record. Maybe I was most interested because Borg is a "de-duplicating" backup method. In other words, Borg does not re-copy the same data on each backup. If Borg has safely backed up a directory or file, and that directory or file has not changed, then Borg leaves it alone.

Learning about Borg was confusing though, and despite me having it working now, and working well, there are still some things that I cannot figure out. They're minor but annoying in that I spent a lot of time on them without getting to solutions.

The main issue is that in my original backup process, I created a list of directories to back up, and put that list into a file. When the process runs, it reads in turn from that file the name of each directory to back up. If I ever decide to add or delete a directory from the process, then all I need to do is to edit that file and the backup process follows the new instructions on its own without needing to be edited.

I could not get Borg to work this way. The best I could do was to get Borg to read the contents of my backup list file and back that up as a single line of data, and then quit. This was after trying everything that I could think of.

Part of the issue may be with bash. Bash is at best obtuse, with a heavy overlay of flat-out weird, and I will never be an expert. And I don't want to be one. Given that though, I have written a bunch of bash scripts to do various things, and my original backup process is written as a set of bash scripts, and it works. Borg resists.

My original process goes through my list of directories to back up and uses tar to put each directory into a separate tar file. That's the backup script itself. I have a second script for the second half of the process.

The second script pushes the backed-up data to whatever external drive is plugged in. All I need to do is to tell this second script which backup this is. I have separate external directories for Sunday through Saturday, another one for mid-month, and another for month-end. Other than that single instruction, entered numerically from a menu as a number from 1 through 9, everything is automatic.

Borg is even simpler and unbelievably faster, but I had to embed the list of directories to back up as literals into the Borg script. So to add, rename, or delete a directory from the Borg version of the backup process, I need to edit the Borg script and not just an external, read-only file.

This is annoying. I'm sure that there is a way to get Borg to read from an external file, but not here, not now, not by me, and no, it's not in the documentation. Not clearly enough to be recognizable and understandable by me.

I did test Borg's integrity by restoring a backup and comparing the total size of the restored data, and checking some of the filenames and file sizes.

That all looked good, but I've decided to keep using my original system for a monthly backup, and for a couple of weekly backups, like Wednesdays and Saturdays. Makes me feel safer. It can't hurt to have a little redundant data lying around, at least until I completely trust Borg, and restoring data from a Borg backup requires Borg to be installed. Restoring from tar backups requires only generic tar software, which is almost universally installed.

But, even given Borg's confusing and incomplete documentation, I do like it a lot.

Actual data backups usually take somewhere in the low hundredths of a second, and writing new data into my repositories takes only a couple of seconds more. I'm almost always done with a backup to one external drive within 15 seconds at most, and that includes connecting the drive, running my Borg script, and unplugging the drive again, even my very slow thumb drive.

Can't beat that one.

So for now, unless I need other features, and happen to find something else that is significantly better, I'm relying on Borg for my routine backup needs. Nothing else does look any better, and most tools look worse.

I did check Restic, which got a slightly higher rating on one review site, but Restic looks far more confusing, much more oriented toward business and server system backups, has even more confusing documentation, and is far less mature. Methinks I don't want to mess with it.

True, Restic is written in Go, while Borg is written in Python, so Restic may be much faster, and may be certifiably much faster, but Borg does my small backups so fast that I would never notice a difference. I don't have terabytes of data to wrangle. With a de-duplicating process, it's more like a few hundred kilobytes per day, if even that much.

So then. I was happy to give up trying to understand Restic at all, and decided to just stick with Borg, which I already had working.

I use Borg daily, it works, and there is no fussing around. Good enough.

Done.

 

Refs:
BorgBackup – Deduplicating archiver with compression and authenticated encryption
Borg Documentation Borg Documentation — Borg - Deduplicating Archiver 1.2.6 documentation
BorgBase - Simple and Secure Offsite Backups
borgmatic

 

---

Have anything worth adding? Then try sosayseff@nullabigmail.com
Me? Temporarily feeling good about myself.

 

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

Planning Madness

The idea of Information Architecture sounds pompous. Or daunting. Or impressive. Or stupid. Or something.

The truth is that the name doesn't matter, but the concepts do. Or maybe not so much the concepts but their application. So can we apply concepts without knowing about them? Sure. Performance counts. Ideas come from life and not the other way around.

Better to do something right without knowing exactly why, or even exactly what you're doing than to know all sorts of things and never do anything. Concepts always come after expertise, after people have tried things various ways, after finding that some things work and others don't. Eventually someone stops, takes a breath or two, and begins to sort things out. That's where concepts come from.

So you can go at it hammer and tongs and bang around, and get something or other done. Maybe even something that works. You have to actually do things to get work done, and doing it does it. But on the other hand you can do much better if you know the theory and apply it well.

So knowing about information architecture can help.

The term comes from Richard Saul Wurman, an architect and graphic designer concerned with presenting information, especially information about urban environments and what goes on in them. These days the term describes ways to organize information in general. How to define it, store it, retrieve it, and then use it efficiently. Information Architecture is the idea underlying good web sites.

The number one reason a web site fails to meet its mission is because that mission is never defined. Information Architecture can help. Think first, then do. That's the idea.

Sounds pretty simple but too many people prefer to fly blind. What usually happens is more like "I like this picture. Let's try building around it and see what happens." Then, later "Let's try something a little more blue." Then, later, more of the same. Meanwhile, back at the ranch, the herd gets restless.

This can go on for years. I've seen it.

When computing was done on the backs of whales, in rooms the size of football fields, and cables lay on the floor like dead pythons, programming was slow and painful. Expensive. One small mistake brought everything to a halt and those warehouses full of hot vacuum tubes sat burning away millions. People learned the hard way. They developed ways to think. Ways to plan. Plans showed how to get from Start to Finish before people actually had to hit the road. They could think first, then act decisively. But there was still much flailing.

Free as birds. When desktop computers came along people figured they could wing it. No thinking needed. Just act. Try one thing and then another, unlike those old creepy guys in white shirts and ties in the glass room. Computer time was cheap.

But programmer time became expensive. And a lot of things never got finished. Because people didn't know where they were or what the destination looked like. More mess. More waste. Time and money. Gone.

Then the web. You didn't need programmers any more. Yay! Just try stuff. Anyone. Everyone. Build a web page and see how it looks. Try another. Tweak it a little until you get it right. Add fonts. More blue. More blinky stuff, maybe. You'll get it right eventually if you try enough times. For sure, dude.

I've worked on projects that ran blindly for years before being thrown away. Cost? Only a few hundred thousand, maybe a million wasted. I've known others who were on bigger projects. Thirty, forty, ninety million down the hole.

Mainframe or web site doesn't matter. Standalone desktop system deployed to several thousand users. Client server app. Web site. All the same.

Think first, then act. Define your purpose, define your goal, then proceed with caution. If you are smart and good and careful you can get the job done. If not you won't. The project will collapse, and if your business is based on success of the project, well bye-bye.

Information Architecture helps. And it isn't even special. No secret sauce. No insider information. No special handshake needed. It is nothing new.

Way back in the old days, long ago, back in the dim 1950s and 1960s people were coming up with ways to plan. A few decided that there must be a right way to do things. People like Grady Booch, Ivar Jacobson, Bertrand Meyer and others. Booch and Jacobson merged their methods into the Rational Unified Process, and Meyer is a fundamental thinker in object orientation who invented design by contract.

Information Architecture is the term that web designers use but it isn't unique. Maybe the web is a bit more like magazine publishing or motion picture producing than traditional software development. A bit more varied in the elements needed. But the basics are the same. Think first, then act. Get things done. Well. Completely. The first time.

From the table of contents of "Getting Real", 37Signals' book on the approach they use, their priorities are:

1. What's the big idea?: Explicitly define the one-point vision for your app.
2. Ignore Details Early On: Work from large to small.
3. It's a Problem When It's a Problem: Don't waste time on problems you don't have yet.
4. Hire the Right Customers: Find the core market for your application and focus solely on them.
5. Scale Later: You don't have a scaling problem yet.
6. Make Opinionated Software: Your app should take sides.

At first glance this looks like a seat of the pants approach but it's not. The idea, the main idea, the big idea, is to decide what you want to do and then do it. After deciding what to do you decide how, and then you do it, and when you are done you stop. And then decide if you've done it well enough.

But nowhere in their process is there any notion of "we'll just try this and see if maybe it works out somehow". The point is to have a destination, produce a map, then follow the map.

One project I was on had to take over a paper form and bring it alive in software. A committee had met for two years. To determine what questions were needed on that form. Finally, knowing that the development team was ready to go, the committee wrapped up work. "Good enough," they decided.

Then they started meeting again. They had no idea what they were up to. Didn't know where they were going or when they were done. Otherwise they could have finished the job in two weeks.

So web people call it Information Architecture. Other people use different words. But the important thing is not to waste time or money or opportunity messing around when what you really need is a plan.

Define your goal. Survey your resources. Pick your team. Build the simplest possible solution. Test it. Review it. Deploy it. Repeat as often as needed. Keep the goal and the plan and the system synchronized. Don't wander around with your mouth open.

You'll come out ahead.

I've chosen to call myself an Information Architect. I mean architect as in the creating of systemic, structural, and orderly principles to make something that informs because it is clear. I use the word information in its truest sense. I call things information only if they inform me, not if they are just collections of data, of stuff. -- Richard Saul Wurman

 

---

Have anything worth adding? Then try sosayseff@nullabigmail.com
Me? Recently nominated for something by someone, somewhere.

 

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

Sometimes It Ain't That Easy

Yeah, so all right, it was about time. Past due in fact. I needed a new computer.

Right?

Sort of.

I've been hammering on a Think Penguin laptop since September, 2014, and it won't last forever. I wish, but no, it won't.

I'm a believer in redundancy. I like to have a backup, and a second backup, and so that way when a failure comes along, I can switch to my first backup. But then I get nervous because I have only one backup left.

It's a thing.

First off, way back when, I bought a System76 Starling, a "netbook" as they were called in those days. It was fine. Slow but fine.

Once I got used to that I bought a "real" laptop from System76. After a year the battery was shot, and a few months later it began rebooting itself, or sometimes just simply switching itself off.

Possibly a RAM problem, but I was living in a place where it would have been awkward to try repairing it, so I bought a replacement from Think Penguin. The first time I switched it on, I had a good feeling, a really good feeling. Strange but true, and that feeling has not gone away in the eight-and-a-half years since.

I love this thing, but when I gave the Starling away (Slow, remember? And too tiny too.) I needed at least one backup, so I bought another System76 laptop. Fine, it's still fine, but aside from setting it up, I've never used it because the Think Penguin is so nice.

Problem Number Two: The new System76 kept switching over to battery power while I was trying to charge the battery. I had to fiddle with the power cord to get it reconnected to the AC line. Running it on straight AC was iffy, because it could just shut down entirely Eventually I caught on and realized that the AC adapter was bad, and shortly after that the adapter quit working entirely.

Well, that was Problem Number Two. Problem Number Three was that I had ordered this laptop with System76's Pop!_OS installed. Yeah, right.

The first time I powered up this laptop, I got a black screen. With a manufacturer-installed OS, the manufacturer's own. That was the desktop. A black screen. I remember that there was something way over on the left side of the screen. It may have been a black icon on the black screen, but anyway, it worked, though all it did was to open a terminal session.

There was no menu, no "buttons" no icons, nothing. And System76 had no online manual, and no one else did either. Beauty, eh?

So I downloaded a copy of Pop!_OS and installed it. Tried, anyway. I wanted to check it out, at least once, but it wouldn't install. No, really — the operating system made by System76 would not install on System76 hardware, so I grabbed a copy of Linux Mint (what I normally use anyway), and installed that. With out a hitch, or a hiccup, or anything. I installed Linux Mint cleanly and effortlessly and thoroughly and forever and IT JUST WORKS as they say. Always has.

Then I went back to using my Think Penguin. That was seven years ago. No problems since.

But I still had only one backup system, and then COVID and such-like and so on, and shortages, and I live way outside North America, so as soon as I could, just before a trip back there, I bought a new System76 Darter Pro with lots more RAM and lots more disk space, and brought it home with me.

Fine and dandy.

At least Pop!_OS worked (and I don't like it), and I haven't seen any hardware problems, but software has been a different issue.

Not horrible, but an issue.

First off, I wanted to see what LMDE was like. That's Linux Mint Debian Edition. But it wouldn't install.

Eventually, with only a tiny amount of fumbling "help" from System76 support, I figured out that the relatively "old" (in a vague sense of that word) software from Debian was not a match with the completely up-to-date sparkly new hardware from System76.

The rule is that, in the Linux world, older hardware is usually a good match with newer software, which is why people can use Linux on 20-year-old, 30-year-old computers. Which is nice, but my situation was backward from that. I was trying to run at least 2-year-old, maybe 3-year-old software, and it was just a pileup. Didn't work. The new laptop choked on it.

Linux Mint, regular edition to the rescue again. Installed just fine, works just fine, probably at least twice as good as LMDE anyway. Meh.

So that was that.

Then, WTF, hardware. All working OK but really?

The battery on this Darter Pro is not removable.

I use my laptops at least 99% of the time in my apartment, with the battery pulled, because (a) I don't need the battery, and (b) leaving the battery in all the time, having it maybe discharge a bit from time to time, and then recharge constantly, well that kills batteries. But no — I'm stuck. Can't remove the fucker.

And two USB ports, only two, one on each side. Only two.

Color me odd, but I use an external keyboard, a "Happy Hacking" keyboard, which I've been using since 1998. (Actually the very same piece of hardware that I bought in 1998.) And I can't use a "standard" keyboard any more, and don't want to anyway, but I have that keyboard, and a mouse, and also a couple of external drives that I use for daily backups, and having only two USB ports is awkward, but here I am. Two USB ports.

I now have a couple of USB "hubs" which help, but that means more desktop cable clutter. Another meh.

Overall I will not say that I am gloriously happy with System76 support, or System76 hardware, and not at all with System76's operating system. Too many problems with the hardware for me. Considering my age, I may never need another laptop, but if I do, I'll go elsewhere. System76 is not my pal.

They followed up by asking me what I thought of their support and I told them, and then they were not happy. Nurk. I'm not either. Go figure.

And though I can't figure out who to blame for the rest, I can say that the rest amounts to the only problems I should have had, in a way.

Problems? Yep — the usual: Different screen resolution, different screen color cast, fiddling with icons, icon sizes, system fonts, loading and configuring software that I use every day, tweaking this and that, downloading something I forgot, and so on.

Emacs has been a bitch.

I really wish that emacs had a more standard plugin system, so someone like me could just select from a menu the few things that I like and be done with it.

There is no doubt that being able to use emacs lisp to virtually rewrite and customize the hell out of exactly every aspect of emacs is crazy good, but I don't know emacs lisp and probably never will and anyway I just want to get a few things done, not enroll in a Ph.D. program to become a certified lisper and then forget it all because I don't use it all day every day.

I have spent weeks (a couple hours at at time) chasing down inscrutable error messages, only to learn the names of startlingly odd configuration variables, only to discover that I still need to fix a wholly different dependency over on the other side, around the back, hiding somewhere in the bushes, just in order to get the damn configuration to be accepted so damn emacs loads so I can do a thing or two, finally.

And the theme would not load, and the spell checker, and all the rest of the crap, and then one of my macros would not work, even though I have not changed it for years. That was fun.

Eventually (a commonly-used word recently, by me) I found that emacs set its "bookmarks" file to be read-only, so that then emacs could not itself write to that file. Yep. Try to figure that one out, folks.

The good news is that when I changed the bookmarks file to a "read-write" configuration, those problems went away. Poof.

When I start emacs, I still do get a message saying "Package cl is deprecated". Apparently no one knows what this means and never will find out, because complaints about this go back years, and no one able to express things in any intelligible human language has been able to either explain it or suggest a fix, in case there is a fix to suggest.

So here we are.

I ordered my System76 Darter Pro in July, 2022, was able to pick it up in November, 2022, and now it's April 2023 and I'm still trying to get it set up. Despite no longer having to work, and theoretically having unbearably empty stretches of time, most of those stretches are already taken, so getting this new laptop functioning has so far been too much like basic scientific research, plus some swearing, and the food around here makes me fart .

Yeah, well. At least I have something to keep me busy, and my Think Penguin laptop has not died yet, and no doubt (if anything unforeseen fails to materialize), then in another week or so I'll be able to switch over to my new Darter Pro and still have Think Penguin in the closet enjoying a nice retirement, but still able to save my sorry butt. Could be worse, right?

At least it isn't raining today.

 

---

Have anything worth adding? Then try sosayseff@nullabigmail.com
Me? Still growing up.

 

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