4 ms·

Having been both a Manufacturing Engineer and a Software Engineer, there are similarities between the two scenarios: work-in-process within a manufacturing faci

Having been both a Manufacturing Engineer and a Software Engineer, there are similarities between the two scenarios: work-in-process within a manufacturing facility and whatever features/functionality a given software development department is creating. I would create detailed step-by-step job instructions for each station in the manufacturing line, along with expected times each unit should take at each station. It was trivial to compare expected versus actual, then dive into the details of what's going wrong if the two values are not matching up (new vendor causing quality issues? machine troubles?). With software, those "job instructions" are little more than the specification hammered out by (hopefully) someone who knows the product, domain, technical capabilities of the software development team (including design and QA). It's rare. Very Rare....any single person can estimate exactly how long a sprint or anything larger is going to take. One wrong technical hurdle, and every estimate is out the window. For the "production worker" on the software dev team, just following those specs wont get them to the finished product. Their knowledge, how well the team can support lack of expertise, shifting priorities...these all create logjams.

gclaramunt 11y ago
my problem is that all the manufacturing techniques I saw being attempted in software development assume each "unit" of production is somewhat equivalent but in my experience thats a very rare occurrence.
EvanPlaice 11y ago
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.

gclaramunt 11y ago

my problem is that all the manufacturing techniques I saw being attempted in software development assume each "unit" of production is somewhat equivalent but in my experience thats a very rare occurrence.

EvanPlaice 11y ago

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.