Software Engineering, Not Computer Science
closed account (z05DSL3A)
I came across this and found it an interesting read:
http://www.stevemcconnell.com/psd/04-senotcs.htm
it even starts with one of my favourite quotes
http://www.stevemcconnell.com/psd/04-senotcs.htm
it even starts with one of my favourite quotes
| “A scientist builds in order to learn; an engineer learns in order to build.” — Fred Brooks |
I have always known that I'm more of a scientist than en engineer. The difference between a scientist and an engineer is something that many people are familiar with through a variety of popular phrases - all variations of the same idea. There was a reason I chose to major in Computer Science and not Software Engineering. Some people actually double-major though.
Last edited on
That is beauty of life. Man uses his two legs to move forward. Computer Science and Software Engineering do the same to help mankind go forward and develop a future for all. We need each other folks. I have never seen a man who says although I am right handed or left handed so I do not need the hand (or leg). He still use both to enjoy his life. We are all different. Some learn by first constructing things. Others learn before constructing. This is beauty in diversity. I love it so.
I disliked the article highly. My criticism:
1. The article defines software engineering but completely fails to define computer science.
2. The practices described as "software engineering" seem to be best practices in any field. Such practices appear to be in complete accordance with computer science.
3. The tone of the article implies that there is some inherent contradiction between "computer science" and "software engineering". The only actual evidence provided for that is an anecdotal reference to a purported computer scientist who hand-tunes a sorting algorithm rather than using some easy off-the-shelf solution. This appears to be the only actual programming reference made by the article.
4. The article does not suggest how the practices of good "software engineering" are to be taught.
Here lies my deepest criticism to the article. I see nothing about "software engineering" (as described there) that can be taught.
Teaching software engineering would be the same as trying to teach people that their work desks should be kept in order. Everyone would immediately agree that an ordered desk is very important. And, if the course consisted of telling you that - noone would protest - but would we need actually to get a degree for taking such a course?
If the only prerequisite for being a "software engineer" consisted in understanding that writing reliable, maintainable software fast and at a minimum cost with maximum user satisfaction is important, then I guess I was a software engineer at the age of 6 (when I copied a basic program from a book into an ancient computer that was hooked up to my parents' tv).
6. The authors' words about scientists is directly offensive. This guy claims that, if given a practical problem, a scientist would make a solution that is either less robust or more costly than the solution of an engineer in the scientists' field. Now this arrogant statement is given 0 evidence. This guy also appears ignorant of the fact that most scientists work on much much tighter budgets and with far smaller salaries than most engineers (for that I must admit I have only anecdotal examples - many more than the total amount of evidence provided by the article).
My verdict of the article: lots of hot air, lots of ego, pumped up into a big big balloon, with essentially zero content.
1. The article defines software engineering but completely fails to define computer science.
2. The practices described as "software engineering" seem to be best practices in any field. Such practices appear to be in complete accordance with computer science.
3. The tone of the article implies that there is some inherent contradiction between "computer science" and "software engineering". The only actual evidence provided for that is an anecdotal reference to a purported computer scientist who hand-tunes a sorting algorithm rather than using some easy off-the-shelf solution. This appears to be the only actual programming reference made by the article.
4. The article does not suggest how the practices of good "software engineering" are to be taught.
Here lies my deepest criticism to the article. I see nothing about "software engineering" (as described there) that can be taught.
Teaching software engineering would be the same as trying to teach people that their work desks should be kept in order. Everyone would immediately agree that an ordered desk is very important. And, if the course consisted of telling you that - noone would protest - but would we need actually to get a degree for taking such a course?
If the only prerequisite for being a "software engineer" consisted in understanding that writing reliable, maintainable software fast and at a minimum cost with maximum user satisfaction is important, then I guess I was a software engineer at the age of 6 (when I copied a basic program from a book into an ancient computer that was hooked up to my parents' tv).
6. The authors' words about scientists is directly offensive. This guy claims that, if given a practical problem, a scientist would make a solution that is either less robust or more costly than the solution of an engineer in the scientists' field. Now this arrogant statement is given 0 evidence. This guy also appears ignorant of the fact that most scientists work on much much tighter budgets and with far smaller salaries than most engineers (for that I must admit I have only anecdotal examples - many more than the total amount of evidence provided by the article).
My verdict of the article: lots of hot air, lots of ego, pumped up into a big big balloon, with essentially zero content.
Last edited on
He makes some good points, but he sort of contradicts himself.
Particularly that the discipline of engineering is not necessarily right for all software development applications; perhaps for mission critical applications like the space shuttle, a missile, a control system for a power grid, or a ventilator, software should be treated with such strict discipline as he says, "full blown software engineering", but in lots of applications, taking the full blown software engineering approach is overboard and gives bad results because it makes for too much red tape, and too ridged of a development system to be able to be fast, dynamic, and adaptable.
I think that to make good software, it's important to do lots of trial and error, and to not be afraid to change your mind frequently. It's very much an art, and it's very much a science if you are seeking perfection. Your initial prototypes are based on hypothesis, you test and evaluate the results and then from your analysis you make improvements.
The issue perhaps is that in big companies, hypothesis, design, research, and programming are separated. They are handled by different people. Maybe it's useful for a big company with so many operations and employees to divide things so cleanly in order to keep organized and be able to manage so many people and so many operations. However, I think that it also has a huge disadvantage in that perfecting the software is necessarily to slow a process. The programmer can't just suddenly have an idea and say, hey, I think the UI would look neat like this, or maybe it would be nice to have this feature, I wonder how useful that would be, immediately start implementing and testing and making decisions. Consequently, a single person could make enormous improvements in the overall product in a single day, whereas the same process, when you have to go through multiple departments, and many people, could take a month, and get all mucked up along the way.
I think a small team of highly skilled people who function as the programmers, and scientists, and perhaps artists as well, can be extremely productive and successful.
And who cares what you title yourself as though, or whether you see yourself building to learn, or learning to build. As a developer, you ought to be learning to build, and learning as you build, from what you build. It's science and engineering and art IMO. To try and make some kind of conversion in the development community from whatever it is, to whatever the author means by "engineering", is like forcing a square peg into a round hole.
Particularly that the discipline of engineering is not necessarily right for all software development applications; perhaps for mission critical applications like the space shuttle, a missile, a control system for a power grid, or a ventilator, software should be treated with such strict discipline as he says, "full blown software engineering", but in lots of applications, taking the full blown software engineering approach is overboard and gives bad results because it makes for too much red tape, and too ridged of a development system to be able to be fast, dynamic, and adaptable.
I think that to make good software, it's important to do lots of trial and error, and to not be afraid to change your mind frequently. It's very much an art, and it's very much a science if you are seeking perfection. Your initial prototypes are based on hypothesis, you test and evaluate the results and then from your analysis you make improvements.
The issue perhaps is that in big companies, hypothesis, design, research, and programming are separated. They are handled by different people. Maybe it's useful for a big company with so many operations and employees to divide things so cleanly in order to keep organized and be able to manage so many people and so many operations. However, I think that it also has a huge disadvantage in that perfecting the software is necessarily to slow a process. The programmer can't just suddenly have an idea and say, hey, I think the UI would look neat like this, or maybe it would be nice to have this feature, I wonder how useful that would be, immediately start implementing and testing and making decisions. Consequently, a single person could make enormous improvements in the overall product in a single day, whereas the same process, when you have to go through multiple departments, and many people, could take a month, and get all mucked up along the way.
I think a small team of highly skilled people who function as the programmers, and scientists, and perhaps artists as well, can be extremely productive and successful.
And who cares what you title yourself as though, or whether you see yourself building to learn, or learning to build. As a developer, you ought to be learning to build, and learning as you build, from what you build. It's science and engineering and art IMO. To try and make some kind of conversion in the development community from whatever it is, to whatever the author means by "engineering", is like forcing a square peg into a round hole.
Last edited on
Topic archived. No new replies allowed.