The difference is, writing code IS the specification process. The code itself is a functional design spec.
The persistent assumption that writing code can be handled like a production process is flat-out wrong. The software equivalent to production is the build/test/deploy phase which any intelligent developer will automate.
The concept of a 'production worker' programmer seems ridiculous. Somebody more experienced researches the domain, comes up with solutions, specifies all those solutions, and the 'production worker' programmer is left to to what exactly? The engineering equivalent is handing a draftsman a hand written drawing and telling them to implement it in CAD. It's good for practice and to get new people up to speed with the process but it doesn't provide much value.
The reality is, unless the team is using an easily repeated process like churning out Wordpress sites from a scaffold generator, there's no such thing as 'job instructions' on a programming team. Each and every developer on the team is assessing the domain and trying to hammer out a specification for the production process. Any part of the process that's easily repeated should -- and ideally --will be automated away.
It's not an easy process to measure because specification requires extensive research and discovery. Bad assumptions are made and corrected. Some approaches require new and novel approaches. A significant amount of the work comes with a great deal of risk.
Throw a few programmers into the mix who lack the battle hardened experience and wisdom of previous successes/failures and they'll generally drag everybody else down.
In short, software development is not a production line. It's hard to define because it requires a lot of unknowns and even more unknown unknowns.
The persistent assumption that writing code can be handled like a production process is flat-out wrong. The software equivalent to production is the build/test/deploy phase which any intelligent developer will automate.
The concept of a 'production worker' programmer seems ridiculous. Somebody more experienced researches the domain, comes up with solutions, specifies all those solutions, and the 'production worker' programmer is left to to what exactly? The engineering equivalent is handing a draftsman a hand written drawing and telling them to implement it in CAD. It's good for practice and to get new people up to speed with the process but it doesn't provide much value.
The reality is, unless the team is using an easily repeated process like churning out Wordpress sites from a scaffold generator, there's no such thing as 'job instructions' on a programming team. Each and every developer on the team is assessing the domain and trying to hammer out a specification for the production process. Any part of the process that's easily repeated should -- and ideally --will be automated away.
It's not an easy process to measure because specification requires extensive research and discovery. Bad assumptions are made and corrected. Some approaches require new and novel approaches. A significant amount of the work comes with a great deal of risk.
Throw a few programmers into the mix who lack the battle hardened experience and wisdom of previous successes/failures and they'll generally drag everybody else down.
In short, software development is not a production line. It's hard to define because it requires a lot of unknowns and even more unknown unknowns.