pnathan | There is no software engineering, or, notes from Industry.

I'm on the record of denying the idea of software engineering. We don't work with the physical the way physical engineers do. We don't have the science<->practice chain the way the regular engineers do. Worse, I think the IEEE SWEBOK is horse poop.

But there's still a practice and rigor to software development. I've been in this world for a few years now, in a few different teams. I've drunk from the wisdom of others. I think I can say something not entirely worthless about the matter of writing good software.

The first thing is the goal.

What is the intended product?
When must it be done by?
To what end are we undertaking this effort?

These questions describe the scale of the effort, the kind of people asked to work on the effort, the tools used during the effort, and the process best implemented during the execution. This is a very simple set of questions designed to understand what the problem is and where you want to go. Put simply, these are the strategic points required to put substrategies and tactics into play.

The common ends in business are "makes us money" or "saves us money". The time it must be done by is usually impossible and best described as "yesterday". The actual product is often mutable and is the usual concern of software creators.

The second thing to consider is the famous cost-quality-speed triangle (pick two). Your company mandates the quality. While you the creator control it, your company may find you lacking if you mishandle it. This is partially true of speed, however.Very few products make or break a company by release date, and software projects are notorious for being late. Particularly when estimates from the line people are disregarded. Cost is, again, something you don't really control for software projects: it's labor + overhead for your workspace + support staff.

As the creator of software, you can materially affect speed and quality. Let us presume that you are going to work your usual 35-45 hour work week and have a reasonable competence at the particular technology that you're dealing with - same as everyone else. How do you manage - from your level as an individual contributor and perhaps mentor to others - keeping things working in alignment with your company? That is the next blog post.

The third thing to consider is politics, or, more euphemistically, "Social questions". An old rule of thumb is that software architecture reflects the organization it was developed in. Another rule of thumb is that people are promoted to their level of incompetence. Yet another is that most organizations stratify vertically and attempt to build internal empires. Let us not assume that our fine institution is not subject to these pressures. It probably has already succumbed in part.

Several implications result from this.

Only you and the others tasked with your project are actually incentivized to complete it. Others may be incentivized to support your organization. Result - when you have to work with other groups, ensure that they have an axe to grind, a wagon to pull, some interest in helping you get your job done. You need them to help, but they can either help you right now or maybe later. I can't remember how many emails I've written that have gotten dropped on the floor.
The software architecture is not per se the best one for the technical task. It did, however, represent a satisficed social architecture for the task & person work division to allow the workers to effectively operate.
Your software probably duplicates someone else's, and they won't want to merge. Your pressure and your silos have subtley different constraints and needs than other silos. Often, the constraint is as simple as "Bob reports to me and fixes bugs the day I ask, but you, Alice, don't report to me and may find my bug to be rather PEBCAK and not fix it". While this is more than slightly silly, it really does have implications. There's no use having centralized software if only some users are served. The others will decentralize themselves and get their jobs done.
Incentives usually produce results designed to ensure more incentives. E.g., if you are not rewarded for fixing problems but instead are rewarded for moving fast, then you won't fix bugs, you'll move fast.

None of these things have to do with software engineering; they hold pretty true pretty well across any producing endeavor. But they lay the context and foundation for the next blog post.