| |
| ▲ | whstl a day ago | parent | next [-] | | I don't think this is gonna happen until we're able to say no to stupid shit pushed on us. When working as an electrical engineer I never had co-workers fighting me on whether I should do stuff that goes against building code. My building engineering friends never had a product manager say "trust me, we don't need this load bearing wall". I know of engineers who did stupid shit at work and got their license revoked, and even some famous ones went to jail. Of course there is the famous Steve Jobs story [1] where he forced Burrell Smith to do a stupid PCB and it didn't work, but Jobs was at least willing to accept that this was a test and would take the fall for the spent money. [1] https://folklore.org/PC_Board_Esthetics.html | |
| ▲ | Wurdan a day ago | parent | prev | next [-] | | I look forward to the day when "good code" becomes as obvious as the best practices in some other engineering disciplines. I like the Practical Engineering YT channel and one thing I always find interesting is learning about all the research and guidance that exists for things I never thought of. Like there are 400 page documents on how to implement drainage in dams based on decades of experience and post-mortem investigations when things went wrong. But it feels like every time I'm involved in a software project, we're starting almost from scratch and just incrementing towards an unknown future which is "good enough". Even if you have a team of experienced developers then the Best Practices at the start of the project are not what they were 2 years prior. The tools that they used on their past projects have evolved (or been deprecated). Or maybe they're being asked to do a bunch of data engineering where they previously did full stack Web development, because org structures are fluid and many IT leaders feel that good engineers can solve any problem with code (ignoring the idea of specialisation). This is not to disagree with your point, but more to say that a lot of the infrastructure and professional norms around classical engineering disciplines just aren't there (yet) for developers. | | |
| ▲ | okwhateverdude a day ago | parent [-] | | > infrastructure and professional norms around classical engineering disciplines just aren't there (yet) for developers. I honestly doubt it will ever get there. Our profession pretty much materialized over night in comparison to other disciplines, and in a rapidly evolving environment, with a much broader application. Only so many bridges/dams/buildings are built in a given time frame and have such incredible capital costs, and human life costs if they get it wrong. It makes sense to carefully curate who and how those things get built. The vast majority of software on the other hand, unless it is for medical/construction/factory equipment that can kill people, is usually super low stakes. And with the democratization of programming in general, even your VBA-curious business analyst can do it in their spreadsheet. Sure I can do the pro se thing in court (and lose my life/freedom), read webmd and treat my own cancer (and die), build my own dam (and flood my neighborhood), but we gatekeep those professions because of the dire consequences of fucking it up. Until software more broadly has those kinds of consequences, there will be no licensure. |
| |
| ▲ | lijok a day ago | parent | prev | next [-] | | I am very glad to hear the positive tone of discourse happening under your thread. I've been arguing for regulation for the software "engineering" "profession" for over a decade now, and am usually met with dramatic recoil. You don't need to write pacemaker firmware to produce severely negative outcomes through ineptitude or indifference. I know of a frontend developer whose UX mistake in a financial mobile app triggered a vulnerable customer to end their life. I've heard stories of people ending up in the hospital because of unmet, unvoiced requirements for tasks delegated to junior developers. It's a strange world we live in where the "profession" with the most (usually unrealized) potential has no oversight. Bob Martin said it best: We either regulate ourselves or we will find ourselves regulated. | |
| ▲ | esperent a day ago | parent | prev | next [-] | | > chlorine gas can be stored in a garage in coke bottles I get the point you're trying to make but you absolutely can't store chlorine gas safely in your garage in a coke bottle. If you try doing this as a business, you'll get shut down hard and possibly some prison time too. On the other hand, WordPress is a valid solution for a huge number of businesses. Perhaps the previous commentor should have labored their point and noted that the engineer's skill is required to know when WordPress is a valid option, and also just as importantly, when it's not. But suggesting the use of WordPress is in no way comparable to doing something illegal like storing chlorine gas improperly. A better comparison would be to using an off the shelf chlorine storage system versus developing your own.
For most companies, off the shelf will be the right choice, but others are doing complex things that require them to develop their own systems. | | |
| ▲ | namaria a day ago | parent [-] | | I have a fairly obscure domain that gets absolutely bombarded by wordpress related scans. This tells me two things: wp seems pretty easy to misconfigure, and a lot of scripts are looking for these misconfigurations. Based solely on that I would never recommend it to a tech-naive business. | | |
| ▲ | esperent a day ago | parent [-] | | We're talking about businesses who have hired a software engineer to advise them on how to set things up correctly. I don't personally have any experience with WordPress, but I assume that it is possible to set up correctly, right? If you hire an expert and pay them to do it, I mean. |
|
| |
| ▲ | Mountain_Skies 2 days ago | parent | prev | next [-] | | I look forward to the day when software engineers have the autonomy that licensed engineers have, so they can tell managers no and if the manager goes around the engineer, the manager and the company end up directly liable for the damage they create. | | |
| ▲ | godelski 2 days ago | parent [-] | | These are in fact the same thing. It is because an engineer can be held liable that results in them being willing to say no. In general, they probably won't be prosecuted, but a common reason for this is that there will be written records of engineers telling management that there are concerning risks. This also results in the job of a Professional Engineer, who is a person who legally puts themselves on the line. They get paid very well and for good reason, they have a lot on the line themselves. I suspect that a big reason CS is not held to the same standards is due to abstraction and that it is still new. But we do live in a time where bad code can get people killed (control systems are the easiest examples), just as building a faulty bridge will. I just hope we don't need a Tacoma Bridge to cause change. Obviously it is harder to figure out things that are more abstract like Social Media (can provide both good and harm). But I'd say, you can always say no. If you're not saying "no" now, that's still a choice you've made. A job is very persuasive, and I'm not saying you're bad for just keeping your head down, just that people should consider where they'd draw the line. The line is personal and different for everyone (which is okay!). Having taken traditional engineering courses, I'll note that ethics is frequently discussed and you're likely to be told you should try to define your line before you asked to cross it. If you don't, you'll likely to cross the line without knowing, as you just didn't know what it looked like. You can always redefine the line as you get more resolution (it continuously updates) but it's much harder to say "no" when you haven't given it much thought. | | |
| ▲ | necovek a day ago | parent [-] | | The main reason we are at a point we are is that it is possible to build very complex software systems cheaply: both the tools and building blocks are abundant and available to everyone. If an engineer tried to build a skyscraper or a bridge, they'd meet challenges other than them having knowledge or professional certification. And to your point, if anyone ever asked an engineer to insert another floor between 8th and 9th floor of a 15 story building, they'd laugh at them. In software engineering, this is possible even if hard. And finally, because of software living a much different life, it will be hard to define criteria for good software. | | |
| ▲ | whstl a day ago | parent | next [-] | | > And to your point, if anyone ever asked an engineer to insert another floor between 8th and 9th floor of a 15 story building, they'd laugh at them. In software engineering, this is possible even if hard. Bingo. For building engineers this is chuckle worthy. For software engineers, it's Wednesday. | |
| ▲ | nearting a day ago | parent | prev | next [-] | | > And to your point, if anyone ever asked an engineer to insert another floor between 8th and 9th floor of a 15 story building, they'd laugh at them. In software engineering, this is possible even if hard. Ah yes, another cocktail party idea [1] where a software engineer pretends like they understand civil engineering. [1] https://danluu.com/cocktail-ideas/ | | |
| ▲ | necovek a day ago | parent | next [-] | | It's great when you make a general statement about somebody you are conversing with without really knowing their background. As Dan notes himself, even scenarios which are simpler than this (moving a bridge, moving a building) are done much more rarely compared to similar requests in software. I did not accidentally use "modify something in a dimension that's really hard to modify in civil engineering" as an example — perhaps your response was a cocktail party response of someone not understanding either civil or software engineering? IMHO, it is all about costs (which I start off with being small in software — comparatively): traditional engineering doing changes like these is extremely expensive and thus they don't (it's usually cheaper to demolish and rebuild). | | |
| ▲ | godelski a day ago | parent [-] | | I really think you should read Dan's post in full. Because you really did make the error him and Hillel discuss. I think it'll also help interpret my point and the gp to my comment. We're not thinking in a framework where CS and Eng are all that different. Or skip to this part of Hillel's video[0] I've been an aerospace engineer. Worked there before coming over to CS. And I can certainty tell you that yes, someone may ask you to split a floor in half. There's nothing really preventing you from doing this. There's buildings with more levels than there are ordered floors. It's a 15 floor building, but you label your floors 1-14. Such an area can be used for things like running conduit or even just as a fire break. Hell, there are even split level homes, you know those ones where you walk in the front door and either go up or down? There's also things like scissor flats. So yeah, you are making the mistake because your example belies you. It illustrates that you aren't aware of the complexities and abstractions in the engineering job. It's okay to have only a rudimentary understanding of engineering, you've spent your time learning other things that are more valuable to you. But that doesn't mean you should assume things are simpler than they are. The truth is that any job, has depth and far more complexity than appears at the surface. While in many jobs you can get away with only doing the simple part, there's still more depth than is actually being utilized. Likely for the same common error. You are right about cost being a big factor, but this is also a very different argument than the one about floor 8 and a half. https://x.com/danluu/status/1484268111687663620 [0] https://youtu.be/3018ABlET1Y?t=920 | | |
| ▲ | necovek 21 hours ago | parent [-] | | Again, you are making assumptions: I have read it in full, and I have experience with construction as well. > someone may ask you to split a floor in half Yes, I've seen it done plenty times. It's especially common with old houses which might have 4-5m high ceilings around here and people do introduce new floors in between. Similarly, with pillars being carrying structures, it is feasible to go and turn 3 floors which are 4m high each into 4 floors ~3m high. But while that's a way to interpret my "original ask" (and all of your examples like hidden floors and such), my intent was clear — in software, you literally go and introduce a whole new thing between the two things that were tighly coupled. Like actual structures above a certain floor. If your implication was followed in software (i.e. try to predict the future and introduce hidden floors, service floors and such) — and it sometimes is — we really end up with worse, more complex software that has technical debt built in from the start. IOW, that's exactly not the way to build software. Again, this does not discount the complexity of civil engineering — it is freaking hard! But my point is that it is DIFFERENT and that same approaches do not necessarily work. | | |
| ▲ | godelski 19 hours ago | parent [-] | | > and I have experience with construction as well.
Just so we're clear, construction isn't engineering[0]. The difference does matter specifically in what we're talking about. > If your implication was followed in software (i.e. try to predict the future and introduce hidden floors, service floors and such) — and it sometimes is — we really end up with worse, more complex software that has technical debt built in from the start.
But again, I think this belies you. Yes, I've made the assumption that you either didn't read Dan's blog in full or listen to Hillel's video, but can you blame me? This sentence is something they both explicitly discuss. You don't have everything figured out in engineering. Frequently you are doing your designs and then get them built by a manufacturer and then reiterate. This is very much akin to writing code, running tests, and rebuilding.Hillel discusses this right here[1] (this also addresses your last line) >> The idea that software is inheriently unpredictable and you're always doing completely new things all the time. While engineering is basically doing the same thing over and over again. Umm... yeah... so... this is probably the only question I got where people would start laughing at me when I asked it.
Or from Dan, not far in he says >> And, of course, only someone who hasn't done serious engineering work in the physical world could say something like "The predictability of a true engineer’s world is an enviable thing. But ours is a world always in flux, where the laws of physics change weekly", thinking that the (relative) fixity of physical laws means that physical work is predictable. When I worked as a hardware engineer, a large fraction of the effort and complexity of my projects went into dealing with physical uncertainty and civil engineering is no different (if anything, the tools civil engineers have to deal with physical uncertainty on large scale projects are much worse, resulting in a larger degree of uncertainty and a reduced ability to prevent delays due to uncertainty).
I'm not interpreting your point too directly, I'm interpreting your point how you're asking I do in the followup. I am telling you the same problems happen in engineering. It is *all* about uncertainty. You are constantly doing new things that people haven't done before. In fact, the entire field of statistics is centered around uncertainty. Randomness is literally a measurement of uncertainty. Yes, it is true that in CS we don't have as formal of a base to derive complex equations and better (but not completely!) account for that uncertainty, but Dan also addresses this immediately after my quote.In fact, let me quote from a footnote of Dan's. #2 >> When I listen to cocktail party discussions of why a construction project took so long and compare it to what civil engineers tell me caused the delay, the cocktail party discussion almost always exclusively discusses reasons that civil engineers tell me are incorrect. There are many reasons for delays and "unexpected geotechnical conditions" are a common one. ***Civil engineers are in a bind here since drilling cores is time consuming and expensive and people get mad when they see that the ground is dug up and no "real work" is happening (and likewise when preload is applied — "why aren't they working on the highway?"), which creates pressure on politicians which indirectly results in timelines that don't allow sufficient time to understand geotechnical conditions. This sometimes results in a geotechnical surprise during a project (typically phrased as "unforseen geotechnical conditions" in technical reports), which can result in major parts of a project having to switch to slower and more expensive techniques or, even worse, can necessitate a part of a project being redone, resulting in cost and schedule overruns.***
(Emphasis my own.) Does that not sound extremely familiar? Rushing for the sake of rushing? That this rushing just incurs technical debt and more surprises? There's surely the constant of management wanting things to be done faster and not recognizing that this creates future trip-ups that create more anxiety to rush and just perpetuates the problems in the first place. > my point is that it is DIFFERENT and that same approaches do not necessarily work.
So I hope you can understand why I had thought you didn't read their arguments. I referenced the timestamp in Hillel's video[1] too. The next part of Hillel's discussion is literally about how much more predictable and consistent SOFTWARE is. *Their entire thesis* is addressing your point.I'll leave you with Hillel again[2] >> people like Pete McBreen and Paul Graham who say that we are not engineers because engineering cannot apply to our domain. Engineers work on predictable projects with a lot of upfront planning and rigorous requirements. Software is dynamic, constantly changing, unpredictable.
[0] I must stress that I'm not trying to say one is more important or better, just that they are different.[1] https://youtu.be/3018ABlET1Y?t=1085 [2] https://www.hillelwayne.com/post/are-we-really-engineers/ | | |
| ▲ | necovek 18 hours ago | parent [-] | | You've missed my entire point which is still not addressed at all with any of the examples you mention. Please note that I never once claimed traditional engineering is predictable — you seem to be stressing a point out of your pre-conviction what a software engineer would believe and not what I am stating plainly. I am talking about a fully "finished" project (say, an apartment building, with people living in those apartments), needing to have a floor inserted in the middle. This is not about "changing requirements", this is about evolving a project that was initially built to be an apartment building into a stadium or an airport without messing up any of the apartment dwellers. Again, this does not mean that the agility and creativity actual engineering needs to posess is at all smaller (in fact, some of the examples that are hard with large physical structures, are trivial with software — like that "moving a bridge" example), but I stay unconvinced that the methods that work for engineering would work as well for software. As I believe most technical debt comes from attempting to predict the future and not rushing, I don't see the parallel there either. Basically, they are arguing points I didn't make and don't believe, and not addressing points I do make and do believe. | | |
| ▲ | godelski 17 hours ago | parent [-] | | > I never once claimed traditional engineering is predictable
I'm addressing this because you are stressing that software is unpredictable. You discuss this point as if it is unique to software. That is why I am pointing out that traditional engineering is highly unpredictable as well. > I am talking about a fully "finished" project
I feel this is quite a narrow viewpoint and I'm not sure exactly how to address this. Do we consider a software project "fully finished"? I feel like you're pushing into a high level of specificity that extends outside the bounds of differentiating software engineering from traditional engineering and is more akin to differentiating software engineering from civil engineering and not from mechanical engineering. Civil engineering and mechanical engineering have different approaches, but their differences do not prevent them from being under the umbrella of "engineering". We're talking at that abstraction level. No one is attempting to claim that everything is similar between software and traditional, just as it'd be ludicrous to say that civil was the same as aerospace (try this with a bunch of aerospace folks, they'll get VERY upset). We're comparing forests, not trees. Yes, the trees make up the forest and they're different, but our discussions are about the similarities and differences in the forests. > this is about evolving a project
Which is quite common in traditional engineering too. I've lost your point tbh. I quoted from both Dan and Hillel who address points in this direction. Are you being more specific? If so, would you elaborate? And does that level of precision even matter? > As I believe most technical debt comes from attempting to predict the future and not rushing
While I agree that rushing isn't the only contribution to technical debt, and I even agree that over planning leads to debt, I think this is a mistake to say that rushing doesn't lead to debt. It should be clear at face value given that we all know that you don't know everything until you get into the code and working with it. Like you said, it is evolving. Meaning you learn as you're going. What's the saying? "Move fast and break things." It's a good motto but it needs an addendum: "clean up, everybody do their share." If you just blast forward to make things you're going to break things along the way. This is perfectly fine, as long as you don't leave a pile of garbage in your wake. That garbage is debt. Conversely you can spend way too much time planning and that too is debt, because as we've agreed, you don't actually know all the issues until you get your hands dirty. There's a balance here and if you're trying to put this on a binary spectrum rather than a continuum then you'll just create debt. There is no single contributing factor to technical debt, it is a multitude. A discussion of one factor is not a claim that there are no others. | | |
| ▲ | necovek 12 hours ago | parent [-] | | I don't think we are able to communicate with each other precisely. When I say "most technical debt comes not from rushing", your counter is that some technical debt comes from rushing, which was never disputed. If I put "fully finished" in quotes, you go on a tangent how software project is never really finished (guess why the quotes). So you address points that are irrelevant or never made, do not address points I do make and only point to other sources which I don't feel they do either. I can come up with examples of electrical and mechanical engineering that are of the same sort, but I would be making cocktail party examples. It seems futile to continue on this thread: thanks for engaging and have a nice day. |
|
|
|
|
|
| |
| ▲ | godelski a day ago | parent | prev [-] | | Obviously never been to floor 7 1/2[0] [0] https://www.youtube.com/watch?v=T2Y7oo3iB40 |
| |
| ▲ | godelski a day ago | parent | prev [-] | | I think you misinterpreted. I mostly agree. But people do program things like cars, planes, and other things that can literally cost human lives. The judgement isn't made on if mistakes happen, but if those that built the thing should have known better. You don't get sued when you legitimately don't know, but you can't be infinitely stupid either. It's about if you should have known. This does include things like not spending enough time or research determining if something is safe, because you can't just avoid answering a question that a reasonable person would have asked. And it has to lead to harm being done. It can help to see what the lawsuits are about. Like Takoma Airbags case[0] where they're being charged with knowing issues. It's for knowingly doing something bad. But you can't avoid asking questions, like in the Challenger Shuttle disaster[1] both NASA and Thiokol ignored signs that the O-rings being used were potentially dangerous and ignored concerns from engineers. While they didn't know the O-rings were defective in cold weather they should have known. With more abstract stuff like Social Media, yeah, we're not in clear cases that are doing harm. No one is going to be prosecuted for inventing nor even building social media. But you can have knowingly harmful practices like manipulating users feeds without consent to perform testing to see if you can make users more happy or sad[2]. The issue isn't that the experiment happened, but that you're experimenting on humans who did not knowingly give consent. You couldn't do that type of a thing with people offline. Offline you need consent before experiments. And you can't just say they'll subject to any experimentation with no warning and grant this privilege indefinitely. Because you should be asking if your experiments might harm people and there's a reasonable belief that it might cause harm. And on the other hand, no one is asking that the devs at wikipedia be sued or lose their programming license just because they created a dark mode where the radio button has an option of "system" but is defaulted to "light". Nor because they didn't go to the lengths is would be to make sure all images properly render when viewed in dark mode. These don't cause harm. Annoying and easy to fix issues, but no real harm has been done. Just petty issues. It can definitely be fuzzy at certain points, especially as all this is new, but it is also okay that things become more defined over time as we learn more. The point is to keep ethics in mind and to be thinking of the consequences of your work. No one is in trouble if you don't hurt someone but you can't walk around never considering the consequences of your actions. It's the work version of not allowing an excuse of "I was just following orders" or "I was just delivering them, I didn't know what was in them". This is not some belief that people should be sued just because they wrote shitty code. But they could IF someone gets hurt AND you used AI to write code because it is cheaper than a person AND knew that the code being written could harm someone. [0] https://www.justice.gov/criminal/criminal-vns/case/united-st... [1] https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disas... [2] https://techcrunch.com/2014/06/29/ethics-in-a-data-driven-wo... |
|
|
| |
| ▲ | cced a day ago | parent | prev [-] | | Developers should get the axe even though there’s an entire process behind pushing code out to production? QA, UAT? Surely people sign off on what’s being pushed out? |
|
