4 ms·

> Software Engineering Unfortunately, I feel like that term has been very diluted in the last few years, to the point where I'm not sure it has much difference

by thearn4 11y ago

> Software Engineering Unfortunately, I feel like that term has been very diluted in the last few years, to the point where I'm not sure it has much difference (at least colloquially) from "programming".

seiji 11y ago
Well, it's typically a multi-year degree program and not a 300 word blog post. https://en.wikipedia.org/wiki/Software_engineering https://en.wikipedia.org/wiki/Software_engineering Then you have Agile and XP and Scrum as either fast-flux Software Engineering (without all the "formal process/documentation" and instead use informal, but blessed, processes and immediate, undocumented, decision making) or anti-software-engineering depending on how you look at it. Think: space shuttle or airliners, not social media. Sure, they still aren't perfect, but if you told me my airplane ran on Ruby I'd rather walk to my destination.
- innguest 11y ago
  It's also typically not an Engineering degree so maybe we should stop calling it that.
  - seiji 11y ago
    You are correct, but it's still the name of an entire field of study. When things have names, we have to use the names the things have when talking about them. The initial page for it on wikiepdia is interesting too (November 14, 2001): https://en.wikipedia.org/w/index.php?title=Software_engineering&oldid=334847426 https://en.wikipedia.org/w/index.php?title=Software_engineer... Especially: Methods have improved through the 1980s and 1990s, but the complexity in requirements have increased fast enough to consume any improvement. There is also a constant eagerness to develop new tools and try the newest tools in each new project. If the programmers are good, the system will work, and the customer will not fully appreciate how complex the task was.
- ebiester 11y ago
  That's a strawman of Agile. Agile is about building the right thing. We found out that gathering the requirements up front and developing an extended timeline and holding deviations to change control ended up building the wrong thing because adapting to change was too painful. We learned that if we wrote software that documented its behaviors in code, it was sometimes more useful than snapshots of technical documentation. Sometimes that isn't true (public APIs and protocols are the first two that come to mind), and thus the appropriate documentation at the appropriate level is justified. We learned that even the best engineers are very poor at how long a task will take, but they are relatively good at estimating how long a task will take relative to other tasks. We learned that we could measure how long these tasks take and get a better estimate of the length of time for a total project. The problem is that the SDLC is a bad process for many classes of software that aren't in the embedded space. Agile is good for some problems (IE, where the requirements are poorly understood) and not others.
  - seiji 11y ago
    Agile is good for some problems (IE, where the requirements are poorly understood) and not others. That's the true answer. There's no one-size-fits-all solution, but people think (and argue) in absolute terms, not situational nuance. People routinely mistake knowing the end-goal requirement ("Make a healthcare website") with knowing every sub-task requirement ("uh... we just spent $500 million with the goal of making a website and nothing actually works!"). We're in a fast society. Nobody wants to spend three years in pseudocode and dependency evaluation and documentation and procedures before laying down real code, so the best we can do these days is augment our decision making as our understanding of the problems and goals evolve then resolve all conflicts and confusions in as real-time as possible.

by thearn4 11y ago

seiji 11y ago

Well, it's typically a multi-year degree program and not a 300 word blog post. https://en.wikipedia.org/wiki/Software_engineering https://en.wikipedia.org/wiki/Software_engineering Then you have Agile and XP and Scrum as either fast-flux Software Engineering (without all the "formal process/documentation" and instead use informal, but blessed, processes and immediate, undocumented, decision making) or anti-software-engineering depending on how you look at it. Think: space shuttle or airliners, not social media. Sure, they still aren't perfect, but if you told me my airplane ran on Ruby I'd rather walk to my destination.

innguest 11y ago
It's also typically not an Engineering degree so maybe we should stop calling it that.
- seiji 11y ago
  You are correct, but it's still the name of an entire field of study. When things have names, we have to use the names the things have when talking about them. The initial page for it on wikiepdia is interesting too (November 14, 2001): https://en.wikipedia.org/w/index.php?title=Software_engineering&oldid=334847426 https://en.wikipedia.org/w/index.php?title=Software_engineer... Especially: Methods have improved through the 1980s and 1990s, but the complexity in requirements have increased fast enough to consume any improvement. There is also a constant eagerness to develop new tools and try the newest tools in each new project. If the programmers are good, the system will work, and the customer will not fully appreciate how complex the task was.
ebiester 11y ago
That's a strawman of Agile. Agile is about building the right thing. We found out that gathering the requirements up front and developing an extended timeline and holding deviations to change control ended up building the wrong thing because adapting to change was too painful. We learned that if we wrote software that documented its behaviors in code, it was sometimes more useful than snapshots of technical documentation. Sometimes that isn't true (public APIs and protocols are the first two that come to mind), and thus the appropriate documentation at the appropriate level is justified. We learned that even the best engineers are very poor at how long a task will take, but they are relatively good at estimating how long a task will take relative to other tasks. We learned that we could measure how long these tasks take and get a better estimate of the length of time for a total project. The problem is that the SDLC is a bad process for many classes of software that aren't in the embedded space. Agile is good for some problems (IE, where the requirements are poorly understood) and not others.
- seiji 11y ago
  Agile is good for some problems (IE, where the requirements are poorly understood) and not others. That's the true answer. There's no one-size-fits-all solution, but people think (and argue) in absolute terms, not situational nuance. People routinely mistake knowing the end-goal requirement ("Make a healthcare website") with knowing every sub-task requirement ("uh... we just spent $500 million with the goal of making a website and nothing actually works!"). We're in a fast society. Nobody wants to spend three years in pseudocode and dependency evaluation and documentation and procedures before laying down real code, so the best we can do these days is augment our decision making as our understanding of the problems and goals evolve then resolve all conflicts and confusions in as real-time as possible.