My chief issues with the way that software is built (not the processes around designing it, figuring out feature sets, taking it to market, all of that -- rather, how it goes from lines in text files to machine instructions) is that it goes the wrong direction and the concepts are 20-30 years old.
Wrong Direction?
The way software has always been built is programmer-centric. This makes sense historically, but modern software is very much not coder-only, and the extent to which all the processes revolve around the developer is a major cause of coordination nightmares for releasing products. Think about all the groups involved in taking a substantial sized software product to market:
- Software Developers
- Testers
- Developers on the test team
- PMs
- Localizers
- UA
- Design
- Builders
- Legal
- PSS
- Beta program managers
- Partner and dependency teams
- Platform teams
- Marketing
- Branding
- Management
- Setup
- I know I'm missing some...
The Right Direction?
Start from the end result! This has normally been the realm of the Byzantine structure that is called the installer, but really should be the goal of the entire build system. This means what registry settings, what files, what settings, etc. The important thing for the files are what exports are required for DLLs, what typelibs are exported, essentially everything that is externally required to be in that file. Everything else should be flexible for performance, optimization, and flexibility reasons.
Old Tech
Why the blazes are we still editing text files to create computer programs? Why do we still have imperfect symbol resolution, imperfect dependency knowledge, weird build rules? Why are resources, which are such a fundamental aspect of production quality software development, still such a tack-on? I'll no doubt rant more about these issues in future entries, I think I've dragged this one along far enough.
Comments