6 ms·

What is Software Engineering?

114 points by stablemap 8y ago

AnimalMuppet 8y ago
It seems to me that computer science is really not programming, but thinking about programming. The problem is, it should also be thinking about software engineering.
- twothamendment 8y ago
  I think CS on its own can be so theoretical and perfect that it is only a part of software engineering. A software engineer who can program can also put that programming and CS to use within business constraints. Hand a strong theoretical CS person a steaming pile of a project and ask for the smallest tweak and it will take forever - that is if their head doesn't explode or they decide to re-architect it. Task a good software engineer with the same thing and they will get the change done with the understanding that they also hate the steaming pile of a project, but it isn't worth any more time.
Joeri 8y ago
The difference between programming and software engineering is the difference between cooking for yourself and cooking in a restaurant kitchen. Similar outcome, radically different methods.
- choonway 8y ago
  yeah... some times you're given a dead dog and told, make it taste like grandma's chicken soup. Not many cooks would be willing to sign up for it, even less have the ability to pull it off.
- AnimalMuppet 8y ago
  To put it slightly differently: software engineering is about efficiently producing working programs at scale. It's like chemistry and chemical engineering. Chemistry is about atoms and molecules, and about chemical reactions. Chemical engineering is about building and running chemical plants that efficiently produce the desired chemicals without blowing up. Though I guess that's the difference between computer science and software engineering, not between programming and software engineering. Maybe in the chemical analogy, programming is pipe-fitting in the chemical plant.
jasode 8y ago
>Software engineering is what happens to programming when you add time and other programmers. To preface, I think there's room for a wide variety of meanings people assign to words and nobody has a monopoly on what "engineering" means. That said, I offer an alternative: Software engineering = programming that accounts for real-world _constraints_ such as performance goals, technology limitations, monetary budgets. Whether engineering a bridge or engineering a circuit board, they share a common theme of optimizing multiple constraints (materials, cost, maintenance, durability, etc). An advantage of this view of engineering is that it can also be applied to solo programming. The single programmer weighs the tradeoffs to a possible solution. The other concept of "add time and other programmers" that the blog author is talking about is also important but in my opinion, I'd prefer the industry find another catchy label for it. I've seen others call it "software factory design" instead of "software engineering". The "factory" of optimizing how multiple programmers work together is what books like Mythical Man Month, Peopleware, etc talk about. To apply my concept of engineering (constraints) back to the Go language... let's say I interview a candidate and ask what his favorite language is and he says "Go". I then follow up and ask "Ok, Go is good. What is Go not good for?" If he responds that he can't think of anything negative, it means he can't do engineering with Go. Engineering means you know the stress weaknesses of concrete, or corrosion properties of steel, or the warts of programming languages. If the candidate then tries to answer with the universal "well, good and bad programming can be done in any language", that's just a restatement of the Turing Tarpit[1] and you can't do effective engineering with that view. Assembly, C/C++, Haskell, Lisp, Javascript all have weak points that work against particular engineering goals. [1] https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit
- varikin 8y ago
  > If he responds that he can't think of anything negative, it means he can't do engineering with Go. I have used this tactic for interviews for quite a while. Though working primarily with Java and the JVM, every good programmer already has a long list of complaints. Regardless of preferred languages, frameworks, etc, everyone should know when their tools are not sufficient. I never care what the answer is other than they are able to articulate an answer.
jhpriestley 8y ago
I don't think that this post really explains much about how to judge the fitness of a feature for software engineering. From the article, `gofmt` supports automated tooling around source code, which is good for software engineering; but scattering import paths throughout the source tree instead of centralizing them in something like `package.json` obviously makes automated tooling around import paths harder, so why aren't local import paths bad for software engineering? The whole viewpoint seems to just add a sort of high-handed argument from authority to your typical subjective arguments over programming features.
- waisbrot 8y ago
  I don't know Go, but I think that automated code-fixes are more difficult than gathering imports. For example, `grep -R -o 'import ".*"' | sort | uniq` gets me a centralized list of imports for the cost of one pass over the code, so maybe it's worth it to side against automated tooling there. But refactoring code is quite hard so a win there is worth the cost.
- AnimalMuppet 8y ago
  I read it as a statement on intent, and a rationale for certain choices in view of the intent. I don't think it's useful to question the intent; that gets too close to accusing people of bad faith. I think the useful questions are: Did your choices actually achieve your intent? And, in doing so, what new problems did you introduce? (You always introduce some new problems.)
- pcwalton 8y ago
  Exactly. To elaborate on that, much of the speed difference between systems like Cargo and dep is that Cargo only has to look at metadata in one file. Surely that is a software engineering advantage!
- deleted 8y ago
  [deleted]
- skybrian 8y ago
  I agree that it's not explained clearly. One possible reason: import statements in source code can be analyzed regardless of which build system you're using. In the case of Go, there are at least two important build systems ("go build" and bazel), so analysis tools would need to support both. On the other hand, if a package.json file were just as universally used as Go source code, it would effectively be part of the language.
panda88888 8y ago
I think software engineering, similar to other engineering disciplines, is applied computer science. It means taking the theory (algorithm, data structure, etc) and create a product (software) that does useful things in the real world. This means the software have to perform functions needed by its users, under real world constraints (time, space, power, cost) while being sufficiently robust to handle noisy inputs and variances. This also means the user will play a large role in driving the evolution and direction of the software and that the scope of software engineering encompassing beyond the theory but to the entire lifecycle of he software product including development, deployment, support, and iterative improvement.
k__ 8y ago
I had it at university and was thinking "Well, programming is just a start, software engineering is where the bacon is!" Whelp... I learned a bunch of UML and SE methods (Rational etc.) and thought I'd go back to programming. Same went with all senior programmers I worked with, they all said "I was a programmer for the longest time! Now I want to become a software engineer!" Just to come out of a certification course and asking "That's it?!" I think the core ideas and principles are right, but after you learned what can be done with code, like infrastructure etc. you don't want to meddle around with stuff that is so far away from code as these methods. It just slows things down too much. The only thing I really liked were class and call diagrams to find out what's going on in legacy codebases.
- wolfgke 8y ago
  > Same went with all senior programmers I worked with, they all said "I was a programmer for the longest time! Now I want to become a software engineer!" Just to come out of a certification course and asking "That's it?!" Semi-relevant: http://programming-motherfucker.com/ http://programming-motherfucker.com/
Jedi72 8y ago
If your life really depended on the ok outcome of the nxt program you wrote, you would make SURE it worked. You test, re-test, try alternatives and compare outcomes, run experiments about what happens under certain conditions. Then you take the level you've tested it at and release it saying that your system is capable of 1/10 what you tested it at. The application of the scientific method to the act of building stuff so that you really know the outcome, at least within known bounds of uncertainty - thats engineering. I'm sure this kind of work does go on throughout the world, but not in 95% of the software that gets written. Just like how engineers aren't involved in 95% of construction jobs, except when writing some guidelines 20 years ago. Most programmers are plumbers and brickmakers building houses, not engineers designing skyscrapers. "When Roman engineers built a bridge, they had to stand under it while the first legion marched across. If programmers today worked under similar ground rules, they might well find themselves getting much more interested in Ada !" — Robert Dewar, President Ada Core Technologies.
- biggc 8y ago
  > Most programmers are plumbers and brickmakers building houses, not engineers designing skyscrapers. Conversely, most mechanical engineers don't end up designing a new production motor, they design a door handle.
nathanaldensr 8y ago
Software engineering is the art of learning to lie to the technically-ignorant around you to satisfy "business requirements."
nudpiedo 8y ago
Software engineering is a whole discipline with several stages, it is mostly technology agnostic for most of the process. There are even people who say that all technology choices are just implementation details, and I do believe the same if I need to think abstract and formulate/define the larger patterns in area domain to work at. That was quite empty article... what’s that? A sales pitch for the next article? The only comment related to design was an implementation detail: the Go modules are git urls. Even at speaking an implementation the article fails: the article does not comment the pros, cons, consequences, problems or typical pitfalls, and evolution in time of this decision; it even does not compare with any other existing choices out there. I believe these kind of articles should not be part of HN since it just aims to exploit the audience. Edit: format

114 points by stablemap 8y ago

It seems to me that computer science is really not programming, but thinking about programming. The problem is, it should also be thinking about software engineering.

twothamendment 8y ago
I think CS on its own can be so theoretical and perfect that it is only a part of software engineering. A software engineer who can program can also put that programming and CS to use within business constraints. Hand a strong theoretical CS person a steaming pile of a project and ask for the smallest tweak and it will take forever - that is if their head doesn't explode or they decide to re-architect it. Task a good software engineer with the same thing and they will get the change done with the understanding that they also hate the steaming pile of a project, but it isn't worth any more time.

Joeri 8y ago

The difference between programming and software engineering is the difference between cooking for yourself and cooking in a restaurant kitchen. Similar outcome, radically different methods.

choonway 8y ago
yeah... some times you're given a dead dog and told, make it taste like grandma's chicken soup. Not many cooks would be willing to sign up for it, even less have the ability to pull it off.
AnimalMuppet 8y ago
To put it slightly differently: software engineering is about efficiently producing working programs at scale. It's like chemistry and chemical engineering. Chemistry is about atoms and molecules, and about chemical reactions. Chemical engineering is about building and running chemical plants that efficiently produce the desired chemicals without blowing up. Though I guess that's the difference between computer science and software engineering, not between programming and software engineering. Maybe in the chemical analogy, programming is pipe-fitting in the chemical plant.

jasode 8y ago

>Software engineering is what happens to programming when you add time and other programmers. To preface, I think there's room for a wide variety of meanings people assign to words and nobody has a monopoly on what "engineering" means. That said, I offer an alternative: Software engineering = programming that accounts for real-world _constraints_ such as performance goals, technology limitations, monetary budgets. Whether engineering a bridge or engineering a circuit board, they share a common theme of optimizing multiple constraints (materials, cost, maintenance, durability, etc). An advantage of this view of engineering is that it can also be applied to solo programming. The single programmer weighs the tradeoffs to a possible solution. The other concept of "add time and other programmers" that the blog author is talking about is also important but in my opinion, I'd prefer the industry find another catchy label for it. I've seen others call it "software factory design" instead of "software engineering". The "factory" of optimizing how multiple programmers work together is what books like Mythical Man Month, Peopleware, etc talk about. To apply my concept of engineering (constraints) back to the Go language... let's say I interview a candidate and ask what his favorite language is and he says "Go". I then follow up and ask "Ok, Go is good. What is Go not good for?" If he responds that he can't think of anything negative, it means he can't do engineering with Go. Engineering means you know the stress weaknesses of concrete, or corrosion properties of steel, or the warts of programming languages. If the candidate then tries to answer with the universal "well, good and bad programming can be done in any language", that's just a restatement of the Turing Tarpit[1] and you can't do effective engineering with that view. Assembly, C/C++, Haskell, Lisp, Javascript all have weak points that work against particular engineering goals. [1] https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit

varikin 8y ago
> If he responds that he can't think of anything negative, it means he can't do engineering with Go. I have used this tactic for interviews for quite a while. Though working primarily with Java and the JVM, every good programmer already has a long list of complaints. Regardless of preferred languages, frameworks, etc, everyone should know when their tools are not sufficient. I never care what the answer is other than they are able to articulate an answer.

jhpriestley 8y ago

I don't think that this post really explains much about how to judge the fitness of a feature for software engineering. From the article, `gofmt` supports automated tooling around source code, which is good for software engineering; but scattering import paths throughout the source tree instead of centralizing them in something like `package.json` obviously makes automated tooling around import paths harder, so why aren't local import paths bad for software engineering? The whole viewpoint seems to just add a sort of high-handed argument from authority to your typical subjective arguments over programming features.

waisbrot 8y ago
I don't know Go, but I think that automated code-fixes are more difficult than gathering imports. For example, `grep -R -o 'import ".*"' | sort | uniq` gets me a centralized list of imports for the cost of one pass over the code, so maybe it's worth it to side against automated tooling there. But refactoring code is quite hard so a win there is worth the cost.
AnimalMuppet 8y ago
I read it as a statement on intent, and a rationale for certain choices in view of the intent. I don't think it's useful to question the intent; that gets too close to accusing people of bad faith. I think the useful questions are: Did your choices actually achieve your intent? And, in doing so, what new problems did you introduce? (You always introduce some new problems.)
pcwalton 8y ago
Exactly. To elaborate on that, much of the speed difference between systems like Cargo and dep is that Cargo only has to look at metadata in one file. Surely that is a software engineering advantage!
deleted 8y ago
[deleted]
skybrian 8y ago
I agree that it's not explained clearly. One possible reason: import statements in source code can be analyzed regardless of which build system you're using. In the case of Go, there are at least two important build systems ("go build" and bazel), so analysis tools would need to support both. On the other hand, if a package.json file were just as universally used as Go source code, it would effectively be part of the language.

panda88888 8y ago

I think software engineering, similar to other engineering disciplines, is applied computer science. It means taking the theory (algorithm, data structure, etc) and create a product (software) that does useful things in the real world. This means the software have to perform functions needed by its users, under real world constraints (time, space, power, cost) while being sufficiently robust to handle noisy inputs and variances. This also means the user will play a large role in driving the evolution and direction of the software and that the scope of software engineering encompassing beyond the theory but to the entire lifecycle of he software product including development, deployment, support, and iterative improvement.

k__ 8y ago

I had it at university and was thinking "Well, programming is just a start, software engineering is where the bacon is!" Whelp... I learned a bunch of UML and SE methods (Rational etc.) and thought I'd go back to programming. Same went with all senior programmers I worked with, they all said "I was a programmer for the longest time! Now I want to become a software engineer!" Just to come out of a certification course and asking "That's it?!" I think the core ideas and principles are right, but after you learned what can be done with code, like infrastructure etc. you don't want to meddle around with stuff that is so far away from code as these methods. It just slows things down too much. The only thing I really liked were class and call diagrams to find out what's going on in legacy codebases.

wolfgke 8y ago
> Same went with all senior programmers I worked with, they all said "I was a programmer for the longest time! Now I want to become a software engineer!" Just to come out of a certification course and asking "That's it?!" Semi-relevant: http://programming-motherfucker.com/ http://programming-motherfucker.com/

Jedi72 8y ago

If your life really depended on the ok outcome of the nxt program you wrote, you would make SURE it worked. You test, re-test, try alternatives and compare outcomes, run experiments about what happens under certain conditions. Then you take the level you've tested it at and release it saying that your system is capable of 1/10 what you tested it at. The application of the scientific method to the act of building stuff so that you really know the outcome, at least within known bounds of uncertainty - thats engineering. I'm sure this kind of work does go on throughout the world, but not in 95% of the software that gets written. Just like how engineers aren't involved in 95% of construction jobs, except when writing some guidelines 20 years ago. Most programmers are plumbers and brickmakers building houses, not engineers designing skyscrapers. "When Roman engineers built a bridge, they had to stand under it while the first legion marched across. If programmers today worked under similar ground rules, they might well find themselves getting much more interested in Ada !" — Robert Dewar, President Ada Core Technologies.

biggc 8y ago
> Most programmers are plumbers and brickmakers building houses, not engineers designing skyscrapers. Conversely, most mechanical engineers don't end up designing a new production motor, they design a door handle.

nathanaldensr 8y ago

Software engineering is the art of learning to lie to the technically-ignorant around you to satisfy "business requirements."

nudpiedo 8y ago

Software engineering is a whole discipline with several stages, it is mostly technology agnostic for most of the process. There are even people who say that all technology choices are just implementation details, and I do believe the same if I need to think abstract and formulate/define the larger patterns in area domain to work at. That was quite empty article... what’s that? A sales pitch for the next article? The only comment related to design was an implementation detail: the Go modules are git urls. Even at speaking an implementation the article fails: the article does not comment the pros, cons, consequences, problems or typical pitfalls, and evolution in time of this decision; it even does not compare with any other existing choices out there. I believe these kind of articles should not be part of HN since it just aims to exploit the audience. Edit: format