Many years back I had a player on the MUCK that was majoring in Software Engineering. I asked them what sorts of things they were doing and what their plans were, only to be told that they didn’t want to talk about that school stuff on their time. They didn’t really care about tech, other than as a job. So be it.

They graduated. I asked what they were seeking. “I’m going to get a job doing process — not grunt coding.” Grunt coding. I pointed out that without experience, they were likely going to start at the bottom like everyone else. They disagreed. They had a BS degree, after all.

It was a few weeks later when they were back and I asked how it was going. “I’ve got a job.” “Doing what?” “Writing reports in VB for a bank.” They didn’t seem at all happy. Granted, after the contempt for grunt coding I couldn’t help myself, “How’s that process working out for you?” They never spoke to me again.

Much of what we do as developers is in fact “grunt coding.” Much of what auto mechanics do is in fact “turning wrenches” too. Like fixing cars or home improvement there are many classes, bootcamps, online courses, self-study programs, books, etc., on the use of our various tools. And like mechanics, knowing how to work our tools is necessary — but it’s not sufficient.

What is necessary to go with what is sufficient?

Continue reading →

Software results from the efforts of many people. At its most basic level, eventually some programmer expresses intention to a computer in a language or mechanism that results in the desired goal being accomplished. Programming is the term, though coding may be more specific. And the choices made by the coders have profound impacts on the results.

As a developer and technical trainer for many decades I have acquired a “feel” for good coding when I see it. And when the code isn’t good, I have often struggled to express why.

There are excellent materials (blogs, books, classes, lectures, journals, etc.) on how to code. Some even cover how to code well. Most, though, handle the objective parts (such as language syntax and expression of logic) much better than the subjective parts.

What makes code good? Or, more useful to this discussion — what makes code bad?

This has been, for me, subjective for too long. There are specific issues which are quantifiable and can be expressed, if I only had the words. Here, then, is one of those issues with the words.

A symptom of accidental complexity that I refer to as brute force.

My purpose is to address one of the aspects I’ve been referring to when I say “I know it when I see it.”

Continue reading →

I founded Redwall MUCK Friday, September 15th, 1995. Redwall MUCK was from the Brian Jacques Redwall novel series.

For those who don’t know, a MUCK is a textual multi-player virtual world. One of the best known MUCK code bases is TinyMUCK (which is the base of Fuzzball MUCK which is what I hacked a few features in for Redwall MUCK). The world is built by players/members (not by programmers). It’s made up of rooms interconnected by exits and with the means for non-programmers to create freely.

The MUCK tech was old in 1995. There are still MUCKs out there (even Redwall MUCK).

Now, the MUCKs aren’t 3D virtual reality, but they are virtual reality. They were absolutely multi-user, and they had community. And each MUCK world is essentially a different place full of virtual places.

Continue reading →

Even though I modified my resume not to match laundry-list job postings I still receive emails from recruiters seeking things like this:

• 8 years working experience developing in JAVA with Microservices.
• Expert in Core JAVA / Spring Boot, Framework, Security, Cloud / Hibernate / Web Services
• Working knowledge of Apache Camel, JMS, JNDI, JUnit, and Cucumber
• Advanced knowledge developing REST APIs and micro-services
• Experience with relational, NoSQL, and event streaming database implementations (Oracle, MySQL, PostgreSQL, MongoDB, Cassandra, Kafka)
• Practical use of XML, JSON, XSLT

So, I guess seven years isn’t enough, eight is the magic number? What are they actually needing? What’s interesting to me is they don’t actually care about programming skills, analysis skills, design skills. What they care about are libraries and products.

It’s almost like what they want is: Coder, Java Enterprise, One (1) each.

Is that really what allows companies to generate extraordinary software?

Continue reading →

A simple example: processing a compressed data file accessed via HTTP (could be API, static website, or any other HTTP source).

I don’t actually care what language, stack, library or framework, etc. Mostly, I don’t care because it doesn’t matter. This problem isn’t about coding, its about performance. So, for the sake of the example, assume the language is fast and the library or framework it uses is exceptional.

Now, the normal approach is this:

1. Fetch the compressed file
2. Decompress the compressed file into a source file
3. Process the source file

This is great, except it takes longer to fetch the file than we’re allowed to wait to start processing the data. And that ignores the decompression time. In short, we have a performance problem. We need to begin showing the results before the bandwidth we have finishes delivering the compressed file.

Well, if it takes 30 seconds to move the data through the wire and we must start showing results within 5 seconds, I guess we’ll need a faster pipe.

Or perhaps we can just do better…

Continue reading →

It’s easy to build software today.

Pick a stack, which gives you a framework from web browser through server. Pick the plugins that hook to your preferred SQL or No-SQL persistence using the mapping technology so you don’t have to code storage directly. Use Docker for each microservice and have them expose web services and setup Kafka for the queueing, with Redis for the shared state. Control it all via Kubernetes and deploy it through AWS.

I’ve been told this, by more than one person and team. “It’s easy.” I’ve never seen any of the teams who claimed it was easy ship.

And yet, everything I wrote above is true. There really are full starting points. There are excellent technologies. I’ve written before about the challenges of attempting to build with enterprise stacks before the problem is well understood, but let’s grant that the problem is understood.

Why, then, is it still so hard to ship software that people can use (and harder to ship software that they like to use)?

Continue reading →

There’s a huge number of books written about how to get things done. Some of them are about personal development, some about project management, some about business strategy, and some are just pragmatics for the general case.

Skipping the computer aspect, just leaving instructions for people is tricky. For instance, something as basic as washing laundry has dependencies and can interleave with other things.

A home washer/dryer example. It would seem a checklist would work:

1. place dirty laundry in washing machine
2. add soap
3. pick cycle
4. start machine

Pretty basic. Except it’s not. The cycle is automatic and may finish in 34 minutes for instance. During that time, then, the person can do something else.

They can interleave the task of doing laundry with another task. They aren’t multi-tasking, per-se, but they can have the washing machine running, they can then load and start the dishwasher (while the washing machine runs) and then do something else, then move laundry from washing machine to dryer …

In short, even simple things in the real world have relationships and temporal inter-dependencies.

How, then, do we let a computer create a plan or schedule, since it would have to be told all of these things?

Continue reading →

I’ve been pondering a common misconception: Microservices are synchronous. Or, Microservices are asynchronous. Both are actually missing the point!

The use of common libraries when implementing microservices using HTTP as a transport has many characteristics of synchronous coding. A request is made, and then one blocks until the result is availble, and then processes the result of the request. That sounds like synchronous code.

However, it’s only the way the code is written that makes it synchronous. For instance, if instead of using a library that takes the request details and returns a set of results, one could use a library that issues the request and then returns without waiting for the eventual results. That would shift the model to asynchronous programming.

So, are microservices synchronous or asynchronous?

What’s the real difference? Actually, it’s easier to show than tell …

Continue reading →

Today I’m working with a founder who is struggling with a common problem. Their application (still running dark, please don’t ask) provides automation for data capture and evaluation for mission critical repetitive tasks.

It’s hard to get time with the people who do the work (my client understands not to ask their boss!) but time was arranged with one of the many people who do the job and will run the application. The client knew not to ask “What are your processes and workflows?” because that question makes no sense to most people. Instead, the question was “What do you do to carry out the task?”

Now, it gets interesting, because other experts must take the same set of inputs and produce the same result … but from less formal earlier sessions it’s clear that each of the experts do things differently.

Now what?

Continue reading →

There’s nothing like the ringing and then silence about the time you grab your phone. When it does occasionally keep going and you answer, there’s a recorded voice, giving you a lie such as “Your auto warranty is about to expire. This is your final notice…”

Of course, we should just hang up.

Or wait through and sometimes there’s a number we can press to be placed on their “do not call list.” Assuming that anyone believes that those who use robo-dialers would honor such a choice.

Or …

Continue reading →