7 ms·

I worked on engineering productivity research and measurement at Google for two years until about a month ago. (Opinions my own.) Compared to my former colleagu

by ftio 5y ago

I worked on engineering productivity research and measurement at Google for two years until about a month ago. (Opinions my own.) Compared to my former colleagues, I'm an infant in this area, so take this with a heaping of salt. In general, I think the author's cynicism about productivity research is justified, but I think it could have been directed more productively. (NB: the following comments say nothing about areas of software engineering research outside of productivity.) Commercial software engineering is a creative endeavor; it is not a science, nor is it a manufacturing process. It does not have natural, universal laws. What makes a team 'productive' varies massively based on constraints imposed by business model, product, customer expectations, leadership values, and of course the individuals of which it consists. I do not believe in the possibility of a "General Theory of Productivity." I'm highly skeptical of attempts to quantify the precise relationship between error discovery stage and cost in a way that is generalizable, although I think it might be possible given a large group of engineers using a highly homogenous process, tools, and accounting. Google is pretty close to this (common dev infrastructure across tens of thousands of engineers), and even across Google this kind of generalization would be extremely difficult. There is no universal physics of software engineering. As a result, academic research into productivity can be difficult to generalize (which is why, I think, you often see researchers twisting themselves into knots). Instead, my rec is to focus on a few key metrics that are aligned with your business' or team's goals (search for DORA for a good starting set) and to reflect often on what you feel makes your team work well and what doesn't.

shusson 5y ago
> Commercial software engineering is a creative endeavor; it is not a science, nor is it a manufacturing process. Do you think software engineering will remain a creative endeavour in the future? We've only been programming in high level languages for 60-70 years. All the while Moore's law has been in effect.
- spaetzleesser 5y ago
  “Do you think software engineering will remain a creative endeavour in the future?” I would think so. If something can be automated or be done with a reproducible process it will get automated or performed by lower paid people. But I can easily see how software and automated processes will reach a point of “good enough” for most purposes sometime in the future and there will be much less software engineers doing creative work. For example I would expect a lot of repetitive front end backend work will go away.
  - justanotherguy0 5y ago
    I would expect the opposite. As the mechanical stuff becomes cheaper and more automated, the creative work decreases in proportion but increases in absolute terms.
- ftio 5y ago
  Oof. I have no idea. But since it'll be fun to guess: Absent some kind of magical (from today's POV) AGI, I think I'd probably say yes, but I'm not sure that means software engineering will continue to look the way it does today, at least not universally. My expectation is a pretty linear extrapolation of history. I think new tools and higher levels of abstraction will emerge that will make certain types of tasks unnecessary or a lot faster. We'll still need people working on compilers and embedded software, but a lot of really basic forms of software development (think Excel replacements) will be A LOT faster and easier to do. Fundamentally, though, business problems are really fucking specific, and you need a really fucking specific language to express and solve those problems. The process of applying those languages to problems is a creative one. I don't think this dynamic will change for a really long time, if ever.
  - svachalek 5y ago
    That's what tools like Visual Basic and Delphi were meant to do, and actually were pretty good at for their time. As far as I can tell, we still haven't nearly caught up to the browser/cloud equivalent of these tools. Things need to sit still for a while longer I guess, but I think there's also some industry changes to blame. In the 90s there was big money in making tools and components for software engineers, while nowadays everyone just uses the best free thing they can find. Granted the free things are way better than they were in the 90s, but I think they're largely killing the market for better things that cost money.
    - petra 5y ago
      Look at low code tools. There's money, market demand, and many tool vendors.
- pvarangot 5y ago
  Music has remained pretty much a creative thing through most exponential explosions of technology that affected it profoundly. What's the most crazy futuristic scenario where software engineering stops being a creative field? We have programming languages for creating and evolving organic lifeforms? You are basically creating plants, pets, "superworkers" or "super soldiers", or artists? That's going to still be creative. Like raising a child is creative. Same thing for stuff that can have an ego driven consciousness like most forms of AGI.
- sanderjd 5y ago
  I think doing the engineering design of structures and machines (buildings, bridges, engines, etc.) is still a creative endeavor after many hundreds of years, and I think this is the closest analogue to what software engineers do. The difference is that once we have the blueprints drawn (ie. the code written), a computer can just execute them rather than requiring a lot more material and labor inputs. Program execution is the right analogue to manufacturing, not program creation.
  - notJim 5y ago
    I agree with this, but those things have also moved from essentially being artisanal to being more formalized and scientific. I don't think we're at that point in software engineering.
    - sanderjd 5y ago
      We're definitely earlier in the timeline with software engineering, but I personally think it seems like structural and mechanical engineering designs are a lot more "artisanal" than is the general conception. Certainly the primitives involved are very well understand scientifically (and this is where we're definitely a long way behind them), but the specific combinations of those primitives strike me as remaining very bespoke and creative, as does the process for creating the designs. All of this looks familiar to me, just further down the maturity timeline.
- narag 5y ago
  My two cents: is that really the problem? I don't think so. I mean that the non-creative part is the problem. Why would anybody want to eliminate the creative part and leave the mindless factory-like part? And there is a huge non-creative, tedious work in programming. A lot of workarounds, minutiae, leaky abstractions, kludges and plain simple idiocy that doesn't get removed because "it's too much work".
phkahler 5y ago
>> I'm highly skeptical of attempts to quantify the precise relationship between error discovery stage and cost in a way that is generalizable... I would say universally that bugs found prior to shipping are lower cost (not just cost to fix) than those found after. I've heard from an auto industry friend that over-the-air update capabilities are becoming mandatory for more components. That sounds good because critical fixes can be issued without the cost of a recall (very expensive - if you're a tier 2 supplier you may be out of business). The down side is that the software teams are starting to think they don't actually need to be "done" by launch day, which leads to a bunch of harder to quantify costs. Another example from a different industry: a bug that caused file import compatibility issues between two versions of the same software. Had that been caught before shipping it would have been no problem to fix. But instead the fix involved trapping an error and rereading the file with a different code path. Also, we didn't realize the change mattered so the file header info was not updated, so we couldn't tell in advance if a file was "old" or "new" when reading it. Once files of both "versions" were in the wild with our customers the simplest (most correct) fix was not possible without braking compatibility.
- WalterBright 5y ago
  > over-the-air update capabilities are becoming mandatory Looking forward to the mass injection of malware into cars exploiting the usual bugs. How about ransomware to get your car started? Lots of fun! > the cost of a recall Mail me a USB stick with the update.
  - concernedtroll 5y ago
    But think of how easy OTA updates will make apprehending criminals! For instance, if a government needs to institute a lockdown to prevent spread of a novel virus, they can just disable all affected citizens' ability to drive anywhere inessential, and the original software doesn't have to support it
- mikepurvis 5y ago
  > The down side is that the software teams are starting to think they don't actually need to be "done" by launch day, which leads to a bunch of harder to quantify costs. See: the disastrous technical state of many modern video games at launch, seemingly especially those extra chunky "live service" titles that are meant to be around for years instead of just a few months like a normal AAA single player game. Examples: - https://kotaku.com/how-biowares-anthem-went-wrong-1833731964 https://kotaku.com/how-biowares-anthem-went-wrong-1833731964 - https://www.forbes.com/sites/insertcoin/2018/11/27/bethesdas-silence-of-the-state-of-fallout-76-at-launch-is-deafening/?sh=3b2bc22461e7 https://www.forbes.com/sites/insertcoin/2018/11/27/bethesdas... - https://www.ign.com/articles/marvels-avengers-keeps-fixing-the-wrong-problems https://www.ign.com/articles/marvels-avengers-keeps-fixing-t... No one would have dreamed of shipping a title on the Gamecube or Playstation 2 that had these kinds of problems— whatever it was you put on that day-one disc was going to be the game forever.
Karrot_Kream 5y ago
> do not believe in the possibility of a "General Theory of Productivity." I'm highly skeptical of attempts to quantify the precise relationship between error discovery stage and cost in a way that is generalizable, although I think it might be possible given a large group of engineers using a highly homogenous process, tools, and accounting. Google is pretty close to this (common dev infrastructure across tens of thousands of engineers), and even across Google this kind of generalization would be extremely difficult. I don't think you are incorrect, but I think a lot of the aspirants behind ESE just want to have a better sense of what works and what doesn't; I'd even welcome negative results! The current state of things is to read 100 opinionated people and their blog posts. And given enough time, you'll encounter someone who swears that after drinking their morning coffee and jumping on one foot for 1 min, they enter a VRChat standup with their team and hit max flow. There's just so little knowledge right now about what works and what doesn't that I'd welcome more clarity, especially negative results. > As a result, academic research into productivity can be difficult to generalize I think defects are what we should measure for, not productivity because of the subjectivity of measuring productivity. But even measuring defects is complicated. The best way I see to measure defects is to ask a Team Under Test to document bugs that they encounter along with resolution times, but this is not only expensive, but something I doubt most corporations will be willing to share outside of their walls. Perhaps open source projects can try to store this data, like curl's stats [1]. [1]: https://github.com/curl/stats https://github.com/curl/stats
musicale 5y ago
> Commercial software engineering is a creative endeavor; it is not a science, nor is it a manufacturing process Exactly. And it's less like movie production and more like 4,000 people trying to collaborate to produce a million-page novel. It does bear some resemblance to design and engineering, but with custom materials and components that have never been used before and need to be created specifically for the project.
- pas 5y ago
  Hm. Every action movie is different, but similar. Every apartment complex is different, but similar. Every webshop is different, but similar. Yes, usually if you have a bad scene it rarely matters, if you have a lot of amazing ones too. And amazing actors, and editing, and ... Similarly, if you build a nice condo, if one face of it looks bad from the street, but the internal spacing of the units are great, then it's still a success. And if your checkout page is shit, but you have amazing search, good prices, great quality products, then your shop is generally great. Of course this makes it sound like engineering, or a specific profession (like that of plumbing, HVAC, electrician tradespeople). It's always never an end in itself. It's complex like a bridge or a dam, sure, but without looking at the big picture (traffic, environment, costs, environment, etc..) it cannot be really evaluated. Even safety eval requires assumption (100 year floods, wind loads, min max temperature, max. traffic load, max ship height under the bridge, max electricity load). And there are patterns, architectures, frameworks. (Like building codes.) There are audits (pentests, like the collision tests for new cars, or synthetic load testing for new sites). The big difference is that usually movies are done in a few years. Scope change rarely affects bridges. After the basic outline of the dam is checked for basic structural sanity, it's done. After a condo master plan is approved the changes are minimal (because there have been many lives lost due to deviations from the plans).
- madelyn 5y ago
  I mean, considering how much code, especially scripting and pipeline work, is required to produce most modern movies, these days most movies are programming projects in one way or another.
- osigurdson 5y ago
jeddy3 5y ago
I seems like many posters in this thread try to classify software enineering as either creative or "mindless factory-work". Where actual enineering disciplines has the risk of removing the creative part. I think this classification is wrong. There IS NO mindless factory-work. Just as in other enineering disciplines, our work is not manufacturing. It's just that the actual manufacturing does not exist (or rather is done by compiler) Software enineering can (just like other enineering) be: - more scientific - more pragmatic - helped by formal methods without removing the creativity. Just as "other" enineering (like software): - is highly creative - can be artisanal (if wanted, rarely in all projects) I REALLY feel we can mature in SWE without being afraid of losing creativity.
- hwayne 5y ago
  Agreed; a while back I interviewed of ex-trad, now-software engineers and found out that 1. Engineering is a lot more personal and creative than we think 2. A large amount of software development is very similar to trad engineering 3. Never walk over a bridge.
- deleted 5y ago
  [deleted]
- madhadron 5y ago
  > It's just that the actual manufacturing does not exist (or rather is done by compiler) In good conditions, yes, the drudgery is all done by the compiler. There's still a terrifying number of cases where something hasn't been automated and still qualifies as factory work.
- Swizec 5y ago
  > It's just that the actual manufacturing does not exist (or rather is done by compiler) Here’s the kicker though: The part that is done by compilers used to be the bulk of software engineering. In his Art and Science book Hamming talks about how programmers rejected the idea of even just automated address assignment. They took great pride in manually managing absolute addressing. Only a sissy who doesn’t know real programming would ever use something so silly as symbolic addressing, to say nothing of compiling from assembly. Ugh! Now we don’t even think about that. Too boring, too solved, too uncreative. There is a lot of engineering that we currently do, which is completely mechanical, mindless, and can be automated away.
pmarreck 5y ago
I can prove that languages may differ in productivity (without regards to other variables like the ones you mention) with a simple "proof by extremes": No one would likely dispute the fact that it will be more productive overall to code in Javascript than in Brainfuck (although perhaps not by much).
Hermitian909 5y ago
The poor ontology backing the term software engineer has always seemed to me like the primary culprit for this problem. I've often heard people doing any of the following for their day job referred to as software engineers: - people who write basic static sties - people who write wordpress sites - people who write simple CRUD apps - people who write hardware drivers - people who write compilers - people who write databases - people who write google-scale distributed systems - people who write graphics engines - people who write physics simulation systems - people who write video games The complexity, depth of abstractions, and expected maintenance lifetimes of these tasks vary wildly, but because we all write source code we're all counted as doing the same job! Sort of an obvious lunacy, different mistakes will punish each of these jobs differently than others.
- ctvo 5y ago
  Do you think other engineers think this way? Your bridge is only 20 yards over a creek, you're not a civil engineer? I'm sure the complexity, depth, and expected maintenance of some bridges vary too.
  - cardosof 5y ago
    This also applies to other fields - medicine for instance.
  - Hermitian909 5y ago
    Based on civil engineers I know I think it's more likely they'd simply consider the engineer making 20 yard bridges more junior, but doing similar work. As I understand it there aren't the same difference in kind that I'm describing here.
  - smnrchrds 5y ago
    In my field (mechanical), there are engineers, technicians, and drafters. Each of the above require more education than the next, and is paid better than the next. Someone who only does drafting work will not describe their job as engineering, nor are companies likely to ask engineers to do drafting because it doesn't make sense to pay someone an engineer's salary for that kind of work. Basic static site seems like drafting. A CRUD app or WordPress site or similar between drafting and technician.
dalbasal 5y ago
>> I do not believe in the possibility of a "General Theory of Productivity." Important frame. I think any effort that doesn't start with this statement is probably headed for frustration. I reckon this is true also for education, aspects of economics and many other fields. Besides sloppy and/or cynical work, I believe a lot of the "replication crisis" relates to this. Do we really expect that a relationship between watching TV at dinnertime and marital sex life observed in 1986 Tokyo to replicate in 2021 Berlin? If it doesn't, does it mean that it doesn't exist, or teach us anything? Scientific academia is sort of premised on the idea that we start from a blank slate, and build up an understanding of a field based strictly in science. It doesn't matter that you already know gravity pulls thing to the ground or that water boils when hot. It must be stated scientifically, tested and theorized. Well... realistically, from this perspective, we know almost nothing about managing people, teaching, lots of things. Yet, we do manage to do them somehow. People all over the world created domesticated cultivars before Gregor Mendel. Science isn't the only framework for knowing things. Writers working on their process don't generally go to "empirical research." They read Stephen King, or one of many other authors that speak about their process. They find one that feels compelling. Often, they describe things in terms like "earning the respect of the muse." Usually, it's a poorly supported framework made of a smattering of methodology, random bits of advice, unique terminology and some innovative semantics. Sound familiar?
- kreelman 5y ago
  I like what you've said here. I'm going to think more about it. Some quite important points. There are parts of dealing with people that can't be science based. I would find it hard to disagree with that. We do try to use science in this realm quite a lot though.... ...I think this conversation around this item is a good example of how sometimes the surrounding conversation is more valuable than the original topic.
- carlosf 5y ago
  Well written!
  - dalbasal 5y ago
Ostrogodsky 5y ago
> Commercial software engineering is a creative endeavor; it is not a science, And do you think Science it is not a creative endeavor? I know that you are coming from the "art/science dichotomy" where the terms are used metaphorically, to me it is an useless distinction still. > nor is it a manufacturing process? Why not? Software production IS a manufacturing process.

by ftio 5y ago

shusson 5y ago

> Commercial software engineering is a creative endeavor; it is not a science, nor is it a manufacturing process. Do you think software engineering will remain a creative endeavour in the future? We've only been programming in high level languages for 60-70 years. All the while Moore's law has been in effect.

spaetzleesser 5y ago
“Do you think software engineering will remain a creative endeavour in the future?” I would think so. If something can be automated or be done with a reproducible process it will get automated or performed by lower paid people. But I can easily see how software and automated processes will reach a point of “good enough” for most purposes sometime in the future and there will be much less software engineers doing creative work. For example I would expect a lot of repetitive front end backend work will go away.
- justanotherguy0 5y ago
  I would expect the opposite. As the mechanical stuff becomes cheaper and more automated, the creative work decreases in proportion but increases in absolute terms.
ftio 5y ago
Oof. I have no idea. But since it'll be fun to guess: Absent some kind of magical (from today's POV) AGI, I think I'd probably say yes, but I'm not sure that means software engineering will continue to look the way it does today, at least not universally. My expectation is a pretty linear extrapolation of history. I think new tools and higher levels of abstraction will emerge that will make certain types of tasks unnecessary or a lot faster. We'll still need people working on compilers and embedded software, but a lot of really basic forms of software development (think Excel replacements) will be A LOT faster and easier to do. Fundamentally, though, business problems are really fucking specific, and you need a really fucking specific language to express and solve those problems. The process of applying those languages to problems is a creative one. I don't think this dynamic will change for a really long time, if ever.
- svachalek 5y ago
  That's what tools like Visual Basic and Delphi were meant to do, and actually were pretty good at for their time. As far as I can tell, we still haven't nearly caught up to the browser/cloud equivalent of these tools. Things need to sit still for a while longer I guess, but I think there's also some industry changes to blame. In the 90s there was big money in making tools and components for software engineers, while nowadays everyone just uses the best free thing they can find. Granted the free things are way better than they were in the 90s, but I think they're largely killing the market for better things that cost money.
  - petra 5y ago
    Look at low code tools. There's money, market demand, and many tool vendors.
pvarangot 5y ago
Music has remained pretty much a creative thing through most exponential explosions of technology that affected it profoundly. What's the most crazy futuristic scenario where software engineering stops being a creative field? We have programming languages for creating and evolving organic lifeforms? You are basically creating plants, pets, "superworkers" or "super soldiers", or artists? That's going to still be creative. Like raising a child is creative. Same thing for stuff that can have an ego driven consciousness like most forms of AGI.
sanderjd 5y ago
I think doing the engineering design of structures and machines (buildings, bridges, engines, etc.) is still a creative endeavor after many hundreds of years, and I think this is the closest analogue to what software engineers do. The difference is that once we have the blueprints drawn (ie. the code written), a computer can just execute them rather than requiring a lot more material and labor inputs. Program execution is the right analogue to manufacturing, not program creation.
- notJim 5y ago
  I agree with this, but those things have also moved from essentially being artisanal to being more formalized and scientific. I don't think we're at that point in software engineering.
  - sanderjd 5y ago
    We're definitely earlier in the timeline with software engineering, but I personally think it seems like structural and mechanical engineering designs are a lot more "artisanal" than is the general conception. Certainly the primitives involved are very well understand scientifically (and this is where we're definitely a long way behind them), but the specific combinations of those primitives strike me as remaining very bespoke and creative, as does the process for creating the designs. All of this looks familiar to me, just further down the maturity timeline.
narag 5y ago
My two cents: is that really the problem? I don't think so. I mean that the non-creative part is the problem. Why would anybody want to eliminate the creative part and leave the mindless factory-like part? And there is a huge non-creative, tedious work in programming. A lot of workarounds, minutiae, leaky abstractions, kludges and plain simple idiocy that doesn't get removed because "it's too much work".

phkahler 5y ago

>> I'm highly skeptical of attempts to quantify the precise relationship between error discovery stage and cost in a way that is generalizable... I would say universally that bugs found prior to shipping are lower cost (not just cost to fix) than those found after. I've heard from an auto industry friend that over-the-air update capabilities are becoming mandatory for more components. That sounds good because critical fixes can be issued without the cost of a recall (very expensive - if you're a tier 2 supplier you may be out of business). The down side is that the software teams are starting to think they don't actually need to be "done" by launch day, which leads to a bunch of harder to quantify costs. Another example from a different industry: a bug that caused file import compatibility issues between two versions of the same software. Had that been caught before shipping it would have been no problem to fix. But instead the fix involved trapping an error and rereading the file with a different code path. Also, we didn't realize the change mattered so the file header info was not updated, so we couldn't tell in advance if a file was "old" or "new" when reading it. Once files of both "versions" were in the wild with our customers the simplest (most correct) fix was not possible without braking compatibility.

WalterBright 5y ago
> over-the-air update capabilities are becoming mandatory Looking forward to the mass injection of malware into cars exploiting the usual bugs. How about ransomware to get your car started? Lots of fun! > the cost of a recall Mail me a USB stick with the update.
- concernedtroll 5y ago
  But think of how easy OTA updates will make apprehending criminals! For instance, if a government needs to institute a lockdown to prevent spread of a novel virus, they can just disable all affected citizens' ability to drive anywhere inessential, and the original software doesn't have to support it
mikepurvis 5y ago
> The down side is that the software teams are starting to think they don't actually need to be "done" by launch day, which leads to a bunch of harder to quantify costs. See: the disastrous technical state of many modern video games at launch, seemingly especially those extra chunky "live service" titles that are meant to be around for years instead of just a few months like a normal AAA single player game. Examples: - https://kotaku.com/how-biowares-anthem-went-wrong-1833731964 https://kotaku.com/how-biowares-anthem-went-wrong-1833731964 - https://www.forbes.com/sites/insertcoin/2018/11/27/bethesdas-silence-of-the-state-of-fallout-76-at-launch-is-deafening/?sh=3b2bc22461e7 https://www.forbes.com/sites/insertcoin/2018/11/27/bethesdas... - https://www.ign.com/articles/marvels-avengers-keeps-fixing-the-wrong-problems https://www.ign.com/articles/marvels-avengers-keeps-fixing-t... No one would have dreamed of shipping a title on the Gamecube or Playstation 2 that had these kinds of problems— whatever it was you put on that day-one disc was going to be the game forever.

Karrot_Kream 5y ago

> do not believe in the possibility of a "General Theory of Productivity." I'm highly skeptical of attempts to quantify the precise relationship between error discovery stage and cost in a way that is generalizable, although I think it might be possible given a large group of engineers using a highly homogenous process, tools, and accounting. Google is pretty close to this (common dev infrastructure across tens of thousands of engineers), and even across Google this kind of generalization would be extremely difficult. I don't think you are incorrect, but I think a lot of the aspirants behind ESE just want to have a better sense of what works and what doesn't; I'd even welcome negative results! The current state of things is to read 100 opinionated people and their blog posts. And given enough time, you'll encounter someone who swears that after drinking their morning coffee and jumping on one foot for 1 min, they enter a VRChat standup with their team and hit max flow. There's just so little knowledge right now about what works and what doesn't that I'd welcome more clarity, especially negative results. > As a result, academic research into productivity can be difficult to generalize I think defects are what we should measure for, not productivity because of the subjectivity of measuring productivity. But even measuring defects is complicated. The best way I see to measure defects is to ask a Team Under Test to document bugs that they encounter along with resolution times, but this is not only expensive, but something I doubt most corporations will be willing to share outside of their walls. Perhaps open source projects can try to store this data, like curl's stats [1]. [1]: https://github.com/curl/stats https://github.com/curl/stats

musicale 5y ago

> Commercial software engineering is a creative endeavor; it is not a science, nor is it a manufacturing process Exactly. And it's less like movie production and more like 4,000 people trying to collaborate to produce a million-page novel. It does bear some resemblance to design and engineering, but with custom materials and components that have never been used before and need to be created specifically for the project.

pas 5y ago
Hm. Every action movie is different, but similar. Every apartment complex is different, but similar. Every webshop is different, but similar. Yes, usually if you have a bad scene it rarely matters, if you have a lot of amazing ones too. And amazing actors, and editing, and ... Similarly, if you build a nice condo, if one face of it looks bad from the street, but the internal spacing of the units are great, then it's still a success. And if your checkout page is shit, but you have amazing search, good prices, great quality products, then your shop is generally great. Of course this makes it sound like engineering, or a specific profession (like that of plumbing, HVAC, electrician tradespeople). It's always never an end in itself. It's complex like a bridge or a dam, sure, but without looking at the big picture (traffic, environment, costs, environment, etc..) it cannot be really evaluated. Even safety eval requires assumption (100 year floods, wind loads, min max temperature, max. traffic load, max ship height under the bridge, max electricity load). And there are patterns, architectures, frameworks. (Like building codes.) There are audits (pentests, like the collision tests for new cars, or synthetic load testing for new sites). The big difference is that usually movies are done in a few years. Scope change rarely affects bridges. After the basic outline of the dam is checked for basic structural sanity, it's done. After a condo master plan is approved the changes are minimal (because there have been many lives lost due to deviations from the plans).
madelyn 5y ago
I mean, considering how much code, especially scripting and pipeline work, is required to produce most modern movies, these days most movies are programming projects in one way or another.
osigurdson 5y ago

jeddy3 5y ago

I seems like many posters in this thread try to classify software enineering as either creative or "mindless factory-work". Where actual enineering disciplines has the risk of removing the creative part. I think this classification is wrong. There IS NO mindless factory-work. Just as in other enineering disciplines, our work is not manufacturing. It's just that the actual manufacturing does not exist (or rather is done by compiler) Software enineering can (just like other enineering) be: - more scientific - more pragmatic - helped by formal methods without removing the creativity. Just as "other" enineering (like software): - is highly creative - can be artisanal (if wanted, rarely in all projects) I REALLY feel we can mature in SWE without being afraid of losing creativity.

hwayne 5y ago
Agreed; a while back I interviewed of ex-trad, now-software engineers and found out that 1. Engineering is a lot more personal and creative than we think 2. A large amount of software development is very similar to trad engineering 3. Never walk over a bridge.
deleted 5y ago
[deleted]
madhadron 5y ago
> It's just that the actual manufacturing does not exist (or rather is done by compiler) In good conditions, yes, the drudgery is all done by the compiler. There's still a terrifying number of cases where something hasn't been automated and still qualifies as factory work.
Swizec 5y ago
> It's just that the actual manufacturing does not exist (or rather is done by compiler) Here’s the kicker though: The part that is done by compilers used to be the bulk of software engineering. In his Art and Science book Hamming talks about how programmers rejected the idea of even just automated address assignment. They took great pride in manually managing absolute addressing. Only a sissy who doesn’t know real programming would ever use something so silly as symbolic addressing, to say nothing of compiling from assembly. Ugh! Now we don’t even think about that. Too boring, too solved, too uncreative. There is a lot of engineering that we currently do, which is completely mechanical, mindless, and can be automated away.

pmarreck 5y ago

I can prove that languages may differ in productivity (without regards to other variables like the ones you mention) with a simple "proof by extremes": No one would likely dispute the fact that it will be more productive overall to code in Javascript than in Brainfuck (although perhaps not by much).

Hermitian909 5y ago

The poor ontology backing the term software engineer has always seemed to me like the primary culprit for this problem. I've often heard people doing any of the following for their day job referred to as software engineers: - people who write basic static sties - people who write wordpress sites - people who write simple CRUD apps - people who write hardware drivers - people who write compilers - people who write databases - people who write google-scale distributed systems - people who write graphics engines - people who write physics simulation systems - people who write video games The complexity, depth of abstractions, and expected maintenance lifetimes of these tasks vary wildly, but because we all write source code we're all counted as doing the same job! Sort of an obvious lunacy, different mistakes will punish each of these jobs differently than others.

ctvo 5y ago
Do you think other engineers think this way? Your bridge is only 20 yards over a creek, you're not a civil engineer? I'm sure the complexity, depth, and expected maintenance of some bridges vary too.
- cardosof 5y ago
  This also applies to other fields - medicine for instance.
- Hermitian909 5y ago
  Based on civil engineers I know I think it's more likely they'd simply consider the engineer making 20 yard bridges more junior, but doing similar work. As I understand it there aren't the same difference in kind that I'm describing here.
- smnrchrds 5y ago
  In my field (mechanical), there are engineers, technicians, and drafters. Each of the above require more education than the next, and is paid better than the next. Someone who only does drafting work will not describe their job as engineering, nor are companies likely to ask engineers to do drafting because it doesn't make sense to pay someone an engineer's salary for that kind of work. Basic static site seems like drafting. A CRUD app or WordPress site or similar between drafting and technician.

dalbasal 5y ago

>> I do not believe in the possibility of a "General Theory of Productivity." Important frame. I think any effort that doesn't start with this statement is probably headed for frustration. I reckon this is true also for education, aspects of economics and many other fields. Besides sloppy and/or cynical work, I believe a lot of the "replication crisis" relates to this. Do we really expect that a relationship between watching TV at dinnertime and marital sex life observed in 1986 Tokyo to replicate in 2021 Berlin? If it doesn't, does it mean that it doesn't exist, or teach us anything? Scientific academia is sort of premised on the idea that we start from a blank slate, and build up an understanding of a field based strictly in science. It doesn't matter that you already know gravity pulls thing to the ground or that water boils when hot. It must be stated scientifically, tested and theorized. Well... realistically, from this perspective, we know almost nothing about managing people, teaching, lots of things. Yet, we do manage to do them somehow. People all over the world created domesticated cultivars before Gregor Mendel. Science isn't the only framework for knowing things. Writers working on their process don't generally go to "empirical research." They read Stephen King, or one of many other authors that speak about their process. They find one that feels compelling. Often, they describe things in terms like "earning the respect of the muse." Usually, it's a poorly supported framework made of a smattering of methodology, random bits of advice, unique terminology and some innovative semantics. Sound familiar?

kreelman 5y ago
I like what you've said here. I'm going to think more about it. Some quite important points. There are parts of dealing with people that can't be science based. I would find it hard to disagree with that. We do try to use science in this realm quite a lot though.... ...I think this conversation around this item is a good example of how sometimes the surrounding conversation is more valuable than the original topic.
carlosf 5y ago
Well written!
- dalbasal 5y ago

Ostrogodsky 5y ago

> Commercial software engineering is a creative endeavor; it is not a science, And do you think Science it is not a creative endeavor? I know that you are coming from the "art/science dichotomy" where the terms are used metaphorically, to me it is an useless distinction still. > nor is it a manufacturing process? Why not? Software production IS a manufacturing process.