I’ve a few friends that are writing novels. I spent a few months banging on what I call a “bad fanfiction” following a bit of advice I read from some professional book on writing fiction. Since it’s not mine (I don’t own the IP, yeah, I’m still a tech guy) I won’t publish it, but it was (and still is, from time to time) really amazing. I have 260,000 words into it, for instance.
And most of them, all but about 250 I think, are junk. So, 259,750 words are garbage. That’s the math.
Those who have read my blog know that I’m a software developer more than a writer. But I discovered that there are many facets that are the same and oddly, some skills that work well in both.
I’ve been skimming Dice to look at the market lately. Of course, most job postings are written with a list of libraries, but I realized when the Wall Street Journal and I spoke about it in my posting on The Staffing Crisis I never mentioned the reason why this approach doesn’t actually help the companies seeking people.
I can appreciate that teams want someone that knows Spring Boot and RESTful API design. They might also want to know how to consume Kafka messages, and they might want to know how to use Redis for pubsub, streams, or state.
What does any of this have to do with dependencies?
Of course, the main tool for implementing those aspects are automated matching systems. I did a bit of an experiment a few months back when I was being bombarded with offers for gigs that made no sense for me. I changed my resume in an intentionally skewed way to ensure that I violated the criteria used by most computer matching systems.
In short, I intentionally broke my resume months before the article. That meant I was an unintentional test of that article.
Enterprise systems are very different from “applications.” It’s almost all because of scale, but scale is a qualitative difference — programs built to “enterprise” or “Internet” scale are not just bigger (key — “just”) but they are dramatically busier.
Consider a blog that receives 2000 “hits” (page-views) a day. That can be served effortlessly using any technology on any hardware platform, from Raspberry Pi to AWS or Azure. This doesn’t mean that the blog isn’t important, or valuable (it could be a blog that is used exclusively by CEOs and world leaders). But it means that the scale is not a technical challenge.
Contrast that with Facebook, Amazon, Google, Twitter, or Bloomberg. They have tens or hundreds of thousand of transactions that involve data being created and altered according to complex rules — per second. These are the companies that caused the growth of enterprise technologies, and that need them.
But how does a solution that needs to go to Enterprise/Internet scale start?
Hint: it’s not with a scalable infrastructure using Docker and Kubernetes with CI via Jenkins.
One of the reasons I love using computers is that, as a developer, the computer performs my wishes.
For most people, it wasn’t until the spreadsheet that the idea of a personal computer became really powerful. It was VisiCalc (and later Lotus 123) that gave business a reason to buy PCs.
And it’s no surprise that Excel is so heavily used today, even far outside of financial or arithmetical projections. Excel allows non-developers to “have the computer do what they want.” Excel allows people to command. They, not the machine, can choose what to enter, where to put it, what math (if any) to perform, and so forth.
The machine obeys them.
This is rarely the case in the software most IT subjects us to.
In a prior article I mentioned a convention of using Excel in a way that ensures a programmer can implement what the spreadsheet represents.
Since a spreadsheet is a program, obviously being interpreted (the XLSX file is being processed by Excel for instance) it doesn’t make sense that a spreadsheet can be created that can’t have its computation implemented in a language like Python.
So, how does a spreadsheet do what can’t be done in software? How is that even possible?
A video game company wants a bedside lamp simulation where the player can:
Plug it in (plug-in)
Unplug it (unplug)
Click the switch (switch)
The lamp may turn on or turn off the light based on these inputs.
Clarifying the User Story
The user story sounds simple enough. I bought a lamp in the real world to use as my basis and discovered that the real lamp didn’t work so simply as the story implied.
I could just assume I understand what the user wants. I’ve got a very good chance of being wrong, but technical people know better, right? No, actually, we don’t.
Instead, I’m going to need to show the customer enough that they can give me a decision on what behavior they want for the lamp in their game. And I may actually need to show a few different kinds of lamp.
The question becomes, then, how do I capture their intention in such a way that all stakeholders understand the same thing? The text didn’t do it … I’ll need to do something better.
I was going to write about the next stage of using Excel for modeling events as well as states during requirements.
I wrote the Excel, Python, and such already, before I discovered that the lamp I bought didn’t obey any of my expectations (see Easy and Simple Isn’t if you haven’t already). Modifying what I did already as my understanding of the problem improved isn’t a challenge, but I started to ponder my premises.
WSJ July 31, 2021: Artificial Intelligence’s Big Chill
The WSJ article is worthy of reading, even if you have to pay for it. I don’t want to steal its thunder, so consider this a recommendation. I don’t get any compensation from it. I can’t link to it, because it’s behind a paywall, but the Wikipedia article defines the definition nicely enough.
An “AI Winter” is what follows irrational exuberance caused by overblown and sweeping claims that imply the computers are going to somehow “be intelligent” like people. Eventually, the people get sick of being misled (or actively lied to, but we’ll call it “mistakenly over-optimistic”) and the party ends.
So, to be clear, the marketing term of “AI” is outrageously stupid.
In attempting to “write the right software” we’re routinely faced with a prose (or worse, spoken) request that the client believes is clear and proper but in fact can’t be unambiguously implemented.
I wrote earlier (Easy and Simple Isn’t) of my attempt to clarify a desktop lamp’s behavior only to discover the electronic lamp had a dimmer built into its power switch.
What does the dimmer do to the requirement? It makes something that was true or false into a range of discrete values.
The simple logic of a light switch (without a dimmer) is functionally this:
next state = not(prior state)
So, if it lit, it becomes not lit. If not lit, it becomes lit.
That’s no longer true if it has a range of values. The behavior of “trigger the switch” (or just “switch” the lamp) actually goes through a sequence that loops on each use of the switch:
This still requires the logic for handling the power cable. If this electronic lamp is unplugged, it always starts on its brightest setting when plugged back in, regardless of what setting it had when unplugged (including off).
The simple requirement to “handle plug in, unplug, and switch the lamp” as prose is clearly insufficient. I could certainly write a more detailed prose requirement, but honestly, the problem with prose is that it can’t be tested. To be tested requires execution — and to execute requires a programmer write it! We have a catch 22 … or do we?