Automated Builds Considered Harmful
From Zanecorpwiki
WIP
"Determining boundaries" is a fundamental part of mastering a craft. "Where does the craft begin and end?" defines the craft, which seems a sensible first step to mastery. At least that's my view.
Where a craft is weakly related to an adjacent node on the process graph, we have a chance to draw a boundary.
That's a terrible way to say it... I've gotten off on some weird tangent.
Look, the idea is that "hardware" and "software" is an easy distinction, but cutting up software construction into a fine grained process is a bit of jumping the gun. I think it could happen, but we're not there yet. The problem is that to divide things up, the boundaries must be well defined in every sense of the word.
They must be well specified. They must be well understood. And they must be well constructed.
I've worked with build systems for 15 years--and I mean really worked with them, I enjoy build systems--and there's just nothing that's close to general solution. There are lots of good "tools" but there's no good, general process.
There are lots of good build systems out there, but the best build systems are always built in house, along with the software as part of the software. All other approaches--in my admittedly limited experience[notes 1]--leave much to be desired.
Automated builds and canned approaches are a decent way to start, but trying to fit a robust, mature, significant project to a canned build process is going to put either the product or the build system out of joint.
This is why I've always liked make. It's just a tool.
Notes
- ↑ Though wide for an individual.
