I know there are a lot of people who are against the term software engineering. I understand why. There really isn't a by-the-books approach to it, yet. The industry is still too young for anything to be highly formalized.
I assure you, that's not the reason. It has nothing to do with age, and everything to do with the nature of programming itself. The "engineering", "assembly line", and "modular" (a.k.a. "LEGOLAND") premise has been proposed countless times over the past 30 years, and summarily proven wrong every single time. No criticism to you, of course, because it feels like it should work that way...but it doesn't hold water in practice, no matter how much research and management gusto we throw behind it.
This isn't engineering because programming isn't science. You need to read my article, The Cake Is A Lie, and then go get a copy of Dreaming in Code by Scott Rosenberg for the full explanation.
Don't misunderstand me, there may well be lessons we can draw from engineering and the assembly line. It doesn't nullify some of your ideas here. It's just that the analogy falls apart when you go beyond a few lessons learned.
Having worked at manufacturing companies, I have to agree with you on this one. The difference will become readily apparent if you have the misfortune to be directly managed by manufacturing oriented engineering management rather than a buffer layer of management "spear catchers" who know software.
In one case, a new operations manager asked why we couldn't just add a second shift of programmers to insure that we meet our project target dates. Others have come up with similar bad ideas.
On the flip side, I had to make them understand how the software development process was different. This often proved a challenge because they want to look at classic project management metrics like "lines of code" and such. Even worse, they think programming a complex web app isn't any different from them recording an Excel macro or doing a calculation and a chart in Matlab.
If it helps, I developed the Quantified Task Management (QTM) standard specifically to address management's need/desire for realistic programming metrics.
I appreciate your answer. It is refreshing to engage about this topic in an open way.
This point I was trying to convey with the post is that we could approach writing programs with the intent of keeping things simple and efficient. The comparison to the assembly line is to guide the point towards the efficiency of doing one thing fast and right over doing multiple things at once.
I don't dare think software should be built in an assembly line.
Of course, whether we should do one thing at a time or multiple things at a time also depends on the nature of the program. One change may necessitate seven others, two of which have to be done concurrently to avoid breaking the software. And then you have the complexity of multiple people working on the code at the same time; one person can be adding feature A, and another adding feature B, and a third fixing bug X. They don't think they're working in the same area (or maybe they do), but they wind up slamming into each other because A needs C and B needs D (which is incompatible with C) and the fix for X blocks both C and D.
Software is messy. :P
But yes, all that aside, I agree that we should (as much as possible) focus on doing one thing right instead of eighteen things half-right.
Now, there is a time when a code base can become TOO DRY (and DRY spaghetti is still spaghetti). Just take a look at the source for libstdc++ (compare and contrast it with LLVM's libc++.)
If we try to make our code too modular, or modularize it too early, it can become harder to maintain, feature-bloat quickly, and take until doomsday to release.
Let's take, for example, my C++ testing library, Goldilocks (part of PawLIB). I wrote it with some interfacing functions, but I hardcoded the shell for it in another application that was using Goldilocks. I needed it functional quickly, so that was NOT the time to build the robust shell.
Then, last week, I knew I needed to set up another project to use Goldilocks as well. Instead of C/Ping the hardcoded shell, I moved that into PawLIB proper, and added some abstraction. I got it functioning well...which, as I think you pointed out, is priority one.
Next, I realized I wanted to simplify the Goldilocks shell commands. While I was at it, I wanted to cut down on repetition, so I moved some common argument validation code into a separate function, and wrote a function for each major shell command. It worked, yay, moving on.
My eventual goal is to actually abstract to the level of writing Blueshell, which will allow an end-developer to just specify the commands, their argument data, and their function callbacks within a Blueshell instance; the shell is automatically created, with all the features you'd expect. That is a level of abstraction a ways down the road, as it will take quite a bit of work to achieve. I'm not there yet, but GoldilocksShell has moved me a few inches closer. I just add one abstraction and feature at a time, until I achieve that eventual modular structure.
So, that's kinda what you're describing, in my mind, but there's an important lesson to be learned for other readers. Well built code isn't always modular in nature. Unlike an assembly line, we can't start with a chassis and add piece by piece to make the final car. Instead, we start with a golf cart someone put together in a hurry (the critical and unavoidable proof-of-concept), and we have to use our assembly line process to convert it into a sports car.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I assure you, that's not the reason. It has nothing to do with age, and everything to do with the nature of programming itself. The "engineering", "assembly line", and "modular" (a.k.a. "LEGOLAND") premise has been proposed countless times over the past 30 years, and summarily proven wrong every single time. No criticism to you, of course, because it feels like it should work that way...but it doesn't hold water in practice, no matter how much research and management gusto we throw behind it.
This isn't engineering because programming isn't science. You need to read my article, The Cake Is A Lie, and then go get a copy of Dreaming in Code by Scott Rosenberg for the full explanation.
Don't misunderstand me, there may well be lessons we can draw from engineering and the assembly line. It doesn't nullify some of your ideas here. It's just that the analogy falls apart when you go beyond a few lessons learned.
Having worked at manufacturing companies, I have to agree with you on this one. The difference will become readily apparent if you have the misfortune to be directly managed by manufacturing oriented engineering management rather than a buffer layer of management "spear catchers" who know software.
In one case, a new operations manager asked why we couldn't just add a second shift of programmers to insure that we meet our project target dates. Others have come up with similar bad ideas.
On the flip side, I had to make them understand how the software development process was different. This often proved a challenge because they want to look at classic project management metrics like "lines of code" and such. Even worse, they think programming a complex web app isn't any different from them recording an Excel macro or doing a calculation and a chart in Matlab.
If it helps, I developed the Quantified Task Management (QTM) standard specifically to address management's need/desire for realistic programming metrics.
I appreciate your answer. It is refreshing to engage about this topic in an open way.
This point I was trying to convey with the post is that we could approach writing programs with the intent of keeping things simple and efficient. The comparison to the assembly line is to guide the point towards the efficiency of doing one thing fast and right over doing multiple things at once.
I don't dare think software should be built in an assembly line.
I can appreciate that.
Of course, whether we should do one thing at a time or multiple things at a time also depends on the nature of the program. One change may necessitate seven others, two of which have to be done concurrently to avoid breaking the software. And then you have the complexity of multiple people working on the code at the same time; one person can be adding feature A, and another adding feature B, and a third fixing bug X. They don't think they're working in the same area (or maybe they do), but they wind up slamming into each other because A needs C and B needs D (which is incompatible with C) and the fix for X blocks both C and D.
Software is messy. :P
But yes, all that aside, I agree that we should (as much as possible) focus on doing one thing right instead of eighteen things half-right.
Now, there is a time when a code base can become TOO DRY (and DRY spaghetti is still spaghetti). Just take a look at the source for
libstdc++(compare and contrast it with LLVM'slibc++.)If we try to make our code too modular, or modularize it too early, it can become harder to maintain, feature-bloat quickly, and take until doomsday to release.
Let's take, for example, my C++ testing library, Goldilocks (part of PawLIB). I wrote it with some interfacing functions, but I hardcoded the shell for it in another application that was using Goldilocks. I needed it functional quickly, so that was NOT the time to build the robust shell.
Then, last week, I knew I needed to set up another project to use Goldilocks as well. Instead of C/Ping the hardcoded shell, I moved that into PawLIB proper, and added some abstraction. I got it functioning well...which, as I think you pointed out, is priority one.
Next, I realized I wanted to simplify the Goldilocks shell commands. While I was at it, I wanted to cut down on repetition, so I moved some common argument validation code into a separate function, and wrote a function for each major shell command. It worked, yay, moving on.
My eventual goal is to actually abstract to the level of writing Blueshell, which will allow an end-developer to just specify the commands, their argument data, and their function callbacks within a Blueshell instance; the shell is automatically created, with all the features you'd expect. That is a level of abstraction a ways down the road, as it will take quite a bit of work to achieve. I'm not there yet, but GoldilocksShell has moved me a few inches closer. I just add one abstraction and feature at a time, until I achieve that eventual modular structure.
So, that's kinda what you're describing, in my mind, but there's an important lesson to be learned for other readers. Well built code isn't always modular in nature. Unlike an assembly line, we can't start with a chassis and add piece by piece to make the final car. Instead, we start with a golf cart someone put together in a hurry (the critical and unavoidable proof-of-concept), and we have to use our assembly line process to convert it into a sports car.