About 15 years ago now, I happened to be talking with a manager who really was not a software type at all. He was explaining a problem that really bothered him, having to collect a bunch of numbers and information, and then do some calculations on it. I listened to him complain, scratched my head a little bit, and said, "Would you like my group to put something together to help with that?"
At the time, I was leading a software development group. We were doing webpages, servers, all that kind of stuff. Frankly, what he was talking about sounded like an easy little project for the team. Probably a web-based form, a tiny bit of calculation, and then provide the results.
He glared at me and said, "No way. I know programmers, it'll cost a fortune!"
I said, "Wait a minute? Just how often do you do this, and how hard is it?"
"We do it every week, and it takes my secretary a day or two every time. But you're going to charge me a fortune to do it in software!"
Then he stalked away, offended that I had offered to take the burden of this job that he complained about, and apparently dumped on his secretary, and turn it into something that the computer would do. Even if it did seem tailor-made for a software solution.
I actually asked my team about doing this. They thought about it, and said the form would take maybe a day, the calculations no more than that. So probably two days of work, or as they put it, "In the worst case, one-man week."
Given that a programmer gets paid better than a secretary, it still doesn't make sense to me. Yes, the secretary can do it, but… 4 to 8 days a month of her time? Even if the programmer is paid four times what the secretary makes, in four months, we're even. And in a year? 52 to 104 days of secretary time versus 5 days of programmer time?
Of course, today, faced with that same problem, I would probably use a Google form, feeding into a Google spreadsheet. Two hours of work to put it together and test it? If that?
Yep, it costs too much. To keep wasting the secretary's time doing simple, repetitious work that a computer can do quite easily.
I'm sure many people have similar stories. But about 35 years ago or so, our company was busily beginning to use Fortran to produce programs for our 8080-based systems. We had done lots of assembly language before. But this was an experimental time, changing over to rapid development using higher order language. When we started looking at what we needed to do, we noticed that there was a lot of string handling in the applications. However, the Fortran libraries that we had really didn't have very much to help.
As almost any good software group would, we immediately formed a committee to design our corporate standard string library. Needless to say, this included the chief scientist, a vice president or two, and sundry experts. As you might expect, discussions immediately started over string formats. Length delimited or end marker delimited were two of the major religions that I can remember, with several variations. The discussions grew heated. Meanwhile, the list of necessary, nice, etc. functions was another battleground.
After more than two months of this, there was no real end in sight. However, as a young project leader with some assembly language experience, I got bored with the endless discussions one day and pulled out my set of "standard routines." With just a little bit of tweaking, they interfaced with the Fortran code just fine.
Based on the meetings, I did run over the list and added a few twists that I had missed. I also tested everything thoroughly, and documented my "Temporary Working String Library (TWSL)." I turned this over to the project team that needed to get our product out, and went back to the standards meetings feeling better. I knew that at least my project could go ahead, and I thought that the eventual standard library would end up relatively close to the temporary one I had produced.
However, when the rumors about my temporary library leaked back to the committee, I was not terribly welcome for a while. I think it was the chief scientist who suggested that my valuable time might be better spent on my project, and he would let me know when they came up with the standard. I know that the meetings continued. For all I know, they may even still be going on.
However, my TWSL was used on that project. And others. In fact, there was a revision 2 that I helped with before it went into general use of the company.
For me, at this point, the interesting thing is looking at the process. Here were several experts, all of whom had done extensive software programming and development with assembly language, Fortran, and using various operating systems. Remember RSX-11M? Several people at the company had cut their teeth pawing through that source. But for some reason, given a chance, they got too busy trying for perfection to get the job done. We didn't need a string library for the ages, we just needed one that we could use today.
Key points: Ensembles are more than just heist stories. Ensemble stories have a team of specialists, each with a different role and part to play, who get together to accomplish some important goal working together. Get people together, let them bounce off each other, and together solve a problem. Why do we like them? We get to see lots of different people, see them interact, and make friends with them. Multiple character arcs intersecting in unique ways. A team of interdependent specialists, hyper competent in individual ways, but holes as a team. How do you make one? Start with a cast of characters, but give each one similar emotional weight. Make sure your characters are specialized enough. They don't all need a POV, plot arcs can happen offstage. One of the keys is introducing the members of your ensemble quickly, usually in action. Make the scene do multiple things. Don't infodump! Think about your competency porn scenes, where you show us how good the characters are at what they do, usually while doing something else at the same time.
[Brandon] Well, we have to stop here. We've gone like 25 minutes almost… [Whoops! Laughter] [Brandon] Yes, but you can tell we love this topic. We will be back to talk about it again in a few weeks. I'm going to give you some homework, though. When we were talking earlier, one of the things we realized is we love ensemble stories that aren't always just the obvious heists. But we do love the heists, obviously, as well. We want you to go look at some different professions, particularly ones that have some sort of front person leading the charge, and, like a chef, maybe on a show like that. We want you to identify all the rules that happen behind the scenes to make that person succeed. We want you to try to design a story that doesn't use the front person at all, and uses all of these different roles supporting them behind the scenes. Do that for a couple different jobs. See what you come up with. We want to give a special thank you to Michael Damian Thomas. [Michael] Thank you for having me. [Brandon] We want to thank the Writing Excuses cruise members. [Yay! Applause] [Brandon] This has been Writing Excuses. You're out of excuses. Now go write.
Mitsuko and I were watching one of the TV shows common here in Japan, with the TV talents happily eating something or other, with extreme expressions of joy as they chew and swallow, followed by ecstatic declarations of how tasty it was... Which is when I realized that there's something wrong with us!
I mean, I enjoy eating, and I have my favorite foods, things that I really enjoy, but. I don't think I have ever made such a joyful face while eating. Nor do I erupt into lyrical announcements of how wonderful the taste is when I eat something I like. Watching the TV folks eat, it seems as if they have a whole different level of engagement with their food from what I get. So I'm wondering if I don't have the right tastebuds, or maybe I'm just not chewing and swallowing the right way?
How do you get that ecstatic experience of eating that the TV seems to indicate is the norm?
This morning the news had a short piece about a group doing their practice emergency drone flights. I missed the location, but this is an area that has had some kind of major disaster in the recent past. The guy was showing us pictures from that -- looked like a flood or mudslide, might have been an avalanche? And he was explaining that one of the problems they had then was just finding where the people were who needed help.
Which is what today's practice was all about. If I understood correctly, this is a volunteer drone squad, and they were practicing the three kinds of drone flights they have developed for emergencies. First, location -- using cameras, including IR cameras, they fly over an area and identify people waving, bodies, and so forth. So they can quickly direct emergency aid to where it is needed. Second, communications! They have drones with speakers, so they can fly over an area and make emergency announcements. Third, supplies. They have drones that can carry at least small medical packs and supplies, so they can deliver those even where emergency vehicles or other aid can't get in.
So, in the event of an emergency, look, up in the sky? Is it a bird, is a plane, is it Superman? No, it's the emergency drones! Looking at you, talking to you, even bringing you the supplies you need.
Morning news had a brief piece about a new vending machine here in Japan. Basically, it looks like a billboard, with the vendor or other information on it, until a customer gets close enough. Then it switches over to a display of the various offerings. You have to know enough to press the offering (I think they should have put clearly marked "Press here" buttons underneath, but... it's new!) but otherwise, it acts just like a normal vending machine. Except that as you walk away, it changes back to a display again.
Basically, they've replaced all those little windows and individual buttons with a big touch panel display. The sensor to detect a customer in range is kind of cute, and I'll bet people will have lots of fun coming up with "not in use" displays. I suppose you could even run the latest ads for your preferred vendors on it...
Of course, it does mean that spotting a vending machine just got a little harder. Look for the coin slots and delivery chute, I guess.
We're watching a retrospective about the Great Hanshin Earthquake. One of the points that they raised is that at least some of the fires that followed the earthquake were due to resuming electrical service! See, apparently when the earthquake hit, power shut down. And in many places, of course, lights, electrical heaters, and other gadgets got bounced around in the quake. But since they had no power, no problem.
But then the electricity started being restored, and... Now the heater laying in a blanket comes on and starts a fire. They are saying that several of the fires in the hour or so window after the earthquake can be traced pretty directly to restoration of electrical power.
Restore service and start fires, or leave the power off and subject people to winter weather without power? They didn't say, but I'll bet some of the power return was automatic, too.
Makes me wonder about building shake sensors into the breaker boxes.
One important point. When I finished reading it, I immediately looked for the next in the series (Chicago!) and bought that. Which should indicate what I thought about this book.
Who should read it? Everybody! It's a romp, basically following two young people (14 and 16 years old, so I suppose this qualifies as a YA, but I think adults can read it too -- I certainly enjoyed it!). One young woman, Alice, and one young man, Joe. Oh, and one young AI, Barton Street (yes, it's the building AI). The plot focuses on the three of them learning to deal with their world, which happens to be composed of dimensional bumps... except that when you open the door the wrong way, you actually go somewhere else. And in those extra dimensions, there are other AI who aren't so friendly. That's probably enough hinting. Read it, you'll enjoy it.
So, the book has several big ideas -- the dimensional bumps, which people are setting up housekeeping in, Alert, which removes the need to sleep, the bios, which are living dolls, the AIs... I think you'll enjoy learning about this brave new world (or is it this rabbit hole?). Don't worry, the author did not go the route of massive infodumps. But the big ideas do add savor.
What else can I say? I'm going to go read Chicago, and I hope you enjoy reading Barton Street Gym. Just watch out for what's behind the door!
There is an oddity. Apparently people are using the term "driverless" for automated cars, and most people are very nervous about that term. The aids -- automated braking, collision avoidance, lane tracking, and so forth -- they are very happy with, even eager to buy, but the whole package with that name on it, no.
Personally, I think I would change the name. Call it driver plus, and go ahead and add all the bits and pieces, including automated driving as a way to help the driver by removing the boring, tedious, repetitive bits and pieces. Emphasize the safety, emphasize letting the driver relax and enjoy the ride. Don't talk about removing the driver, do talk about letting them make the important decisions, where to go, which alternatives to take, where to stop along the way, while the car does the grunt work of controlling speed, watching for other cars, staying on track and so forth.
Heck, you could do a John Henry contest. Have a driver plus car take on a regular driver, with the question of who gets there and is well rested, ready to party? Do you really want to spend your entire trip making those tedious small decisions or would you rather make the big decisions and leave the minute-to-minute driving to the car?