Green Fields Ahead

I can do anything!

Greenfield projects in software imply that there won’t be a legacy system to accommodate, so this time, everything can be done right and all that “old cruft” can be ignored and we’ll all be coding in a land of rainbows and joy with only sunshine.

The reality is, greenfield projects are considered more risky. My earlier article on Getting to Enterprise explains one warning about greenfield risk — starting with enterprise tech because “you’ll need it anyway.”

Feel free to search for articles on the risks of greenfield development. This article focuses on what the coders need and do during greenfield and where not having legacy helps and hinders them.

Continue reading

The Amazing World of Step/Graduated Tables

Really? Tax Tables?

This isn’t a topic most people would find interesting, until they are subjected to implementing graduated or step tables. And I’ve found that many people aren’t aware of how a progressive tax model works even when seeing the tables.

I bring this up because when implementing a tax calculator using those tax tables if the tables are followed “as written” from most sources the code can generate wrong values and can even claim there are no brackets!

Credit to the Internal Revenue Service — its tables are defined properly!

How can so many be so wrong and what’s the actual error? And is the error in more than tax tables? Well…

Continue reading

The Reification Abstraction

One of the areas I enjoy is problem domain modeling. Developers have a tendency to skip this and immediately plunge into solutions. This works for them when the problem is understood…which is true far less often than they think.

Reification is a term used in many domains, but it’s easy to show it in problem modeling — and it’s often known (though not named) so if it seems familiar, excellent. (If you have experience in databases, it’s a part of normalization as well.)

To show an example, I’d like to model something that is not nearly as simple as it sounds, and use conceptual reification to address it.

Continue reading

DoorDash and the Two Audiences Failed

I like DoorDash and have used them for a few years, across many cities (I travel often, I’m not sure what their analysis makes of the various places I’ve ordered from).

What’s amusing is that my home in Las Vegas is one of many where the routing algorithm used for their drivers takes them to the wrong place every single time. I’ve updated my delivery directions to include the cross streets that bracket my condo, but it never helps.

A driver finally showed me why … and it’s a classic example of either bad analysis or bad design in the UX.

Continue reading

Mandated Lack of Security for Security’s Sake

I needed a QuickBooks Desktop license to access a company file for a lawsuit, so I bought one. Being paranoid, of course I put it on a machine not on the internet so that nothing I did could expose it (it’s not my data, of course I wouldn’t want it accessible online).

Since I did have the new QB Desktop (QB Premier 2021) I fired it up to experiment with importing transactions.

And discovered that in order to use QB Desktop I had to be online and logged into Intuit.

For my security I had to expose my accounting data to the internet …

What?

Continue reading

Keep On Supporting Them!

I wrote about how people and companies should help people learn to develop software who didn’t take the traditional university route (Developing Developer’s) and the Wall Street Journal today posted success stories of some who have taken non-traditional paths successfully in Blue-collar Workers Make the Leap to Tech Jobs. No college Degree Necessary.

This will, I hope, entice the recruiters who are seeking people expand their nets for entry level people. Job postings that demand degrees and many years of experience in a laundry list of tools will easily reject the people who have done what the journal article reports. I wrote about this last year in The Staffing Crisis. The same problem remains among the less skilled recruiters.

Continue reading

Trusting Everything?

The Wall Street journal today just posted an article Apps with Hidden Data Harvesting Software are Banned by Google, which is just one of many. I’m not even going to say it’s more egregious than many.

I worked on cybersecurity compliance for the nuclear power industry for a few years. I wasn’t doing the cyber protection itself (I’m not a security administrator, computer or network) but rather the software that enabled them to track all the details per NEI-0809. I learned a lot more than I ever wanted to know about security, and that includes having worked with classified data (oddly, as a site adminstrator) in USAF and having security certifications.

We want to trust; we want to believe that what we download, what we draw in from public repositories, even what we buy, is secure. It’s not.

Continue reading

Developing Developers

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

Recognizing and Responding to Brute Force

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