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.
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…
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.
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.
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 …
I’ve setup a single page website “brochure” for analysis services (link at the very bottom of this post). I don’t think most people realize that the sort of analysis that is done in software development can be used for solving many different problems. I’m going to see if I can help them.
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.
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.
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.
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.”