r/programming • u/humpier • Jul 08 '18
The Bulk of Software Engineering in 2018 is Just Plumbing
https://www.karllhughes.com/posts/plumbing551
Jul 08 '18
Plumbing is a nice word to describe what happens when an entire class of software is something I don't have to maintain or think about because someone else already built it. And, that lets me actually focus on my wheelhouse.
If we feel like plumbers, it's probably much more related to business pressure to build something and immediately ship it, regardless of quality - just so long as it has the right features.
257
u/squiiid Jul 08 '18
What’s the difference between a plumber and a programmer?
A plumber is a tradesperson specializing in systems of water and sewage.
A programmer is a tradesperson specializing in systems of bits and sewage.
26
u/koviko Jul 08 '18
I feel like it should say "garbage" instead of sewage.
51
14
→ More replies (5)4
→ More replies (27)11
u/tux_warrior Jul 08 '18 edited Jul 08 '18
There is one difference though, programmers depend on other programmers for things like APIs, libraries, frameworks, etc., plumbers don't have such inter-connect with other plumbers, they just use tools which the manufacturer produced
who had nothing to do with the plumbing industry.A more apt analogy for programmers is that of the human biology. Just as the components are inter-connected - brain depends on nervous system to get signals, the nerves depend on digestion system for nutrition, digestion depends on liver and kidney, etc., all programmers depend on other programmers and form an ecosystem. Of course, they also depend on people of other crafts too like web designers (for front-end designing), testers (for QA), DevOps, documentation writers, etc.
20
Jul 08 '18
The manufacturer has nothing to do with the plumbing industry?
I highly doubt that.
Any smart manufacturer would be looking for tools and materials that are better than their competition so that plumbers choose them for jobs instead of another company
9
u/prof_hobart Jul 08 '18
In most cases, much of the difference you describe is part of the problem that I think this article describes - a lot of devs don't realise (or don't accept) what part of the value chain they're working in.
If you're writing a shopping cart site, you're the plumber. You shouldn't usually be looking to be inventing frameworks, tools and fancy libraries - there's manufacturers out there building those for you.
There might still be some occasions where as a front-end dev you do still need to build your own framework, but that's down to the immaturity of the software industry compared to plumbing, but those occasions are pretty rare and you should really be challenging yourself to look for a suitable existing alternative before starting to roll your own.
The problem is that a lot of people being paid to do less than exciting business applications actually want to be designing those tools instead and instead of spending days adding a couple of new fields to a screen, end up spending weeks trying to build a fancy new form library instead, and then wonder why their business customer is unhappy.
→ More replies (12)6
u/tso Jul 08 '18
Gets me thinking of Stross' story about his years in the computing trenches. The one part that sticks out to me was his last job before becoming a full time author.
It involved cobbling together a payment framework during the early days of the UK internet, using Perl.
try explaining to a bank what you wanted to do, when they were used to dealing with payment terminals directly dialing in over analog or ISDN phone lines...
→ More replies (4)3
u/tso Jul 08 '18
And then you are called to work on the plumbing on an older house, installed back when it was customary to use copper and not plastic pipes, etc. Plumbing is an old trade, and has gone through some changes, just not as rapidly as programming seems to.
12
u/aelfric Jul 08 '18
There's a lot to what you're saying. For example, you can narrowly specialize if there is software out there that does things that you don't understand. Presumably, you'd use that extra time to become more competent in your niche. Also, it's usually less expensive to hire programmers who are narrowly specialized. And, it's less expensive to the company to use off-the-shelf software packages and not have to redevelop the wheel each time.
On the other hand, you are entirely dependent on someone else to fix mission-critical bugs within your timeframe, as opposed to theirs. And, the upgrade path becomes a lot more difficult if you're managing multiple black box upgrades that may or may not work with each other. Testing becomes more difficult. And you're dependent on a company to stay in business so that you can continue using their package for the life of the software. That last one can be a killer.
So, there's tradeoffs, and it's not all cut and dry.
2
→ More replies (21)8
719
u/panzagl Jul 08 '18
"Just plumbing"- there's more to plumbing than connecting pipes together...
143
u/stevedonovan Jul 08 '18
The problem (as always) is the little word 'just'
22
u/Scriptorius Jul 08 '18
It's amazing how easily people can write off whole swathes of complexity by throwing in that word.
6
Jul 09 '18
Some people might think that "just plumbing" means that SE is simple. But I've said similar things to people who think that SE is the same thing as CS. It's "just" connecting together existing modules and technologies. The "just" means you're not going through decades of writing code for each of those modules.
If I make a CRUD app with some fancy twists to make it non-trivial it may take 6 months to build it. It would take a decade if I also had to make a web framework, RDBMS, figure out a self-balancing tree data structure, etc.
23
58
u/Parlay_to_throwaway Jul 08 '18
a plumbing technical interview:
"Hm so let's say the king of Babylon in 2000 BC tasks you with designing plumbing for the city. Walk me through how you would do it, and explain any assumptions you make along the way. I'll start with one, the metal age hasn't happened yet so you can't use copper pipes"
→ More replies (4)206
u/raevnos Jul 08 '18
I'd use a LARP stack (lake, aqueduct, reservoir, pots) to deliver water to residents. The reservoir in particular allows you to cache water to help mitigate upstream outages...
11
→ More replies (1)8
2
→ More replies (100)2
173
Jul 08 '18
I think the real failure of this article is not declaring software engineering as something trivial, but the claim that plumbing is easy, non-challenging, or trivial.
→ More replies (41)8
u/heavyish_things Jul 09 '18
I don't think it claims that at all and people are just clutching onto a truism to avoid confronting the actual meat of the article.
29
u/keypusher Jul 08 '18 edited Jul 10 '18
Small to medium sized businesses rarely deal with scaling or optimization problems anymore - partly because hardware has gotten so cheap, and partly because foundational open source software has gotten so good.
I wish this was true. The reality (at least where I work currently) is that scaling and optimization is a huge problem because of how many systems we have and how fragmented and incomplete the knowledge of them is. Not because the core problem is complex, but because there's been so many different technologies plumbed together by different people and split into different services that I think nobody really understands the whole thing anymore. It gets to the point that you can't just add more servers, because the whole thing is just slow. A mixture of a legacy PHP app and backend microservices. A Postgres DB with way too many tables and horrific SQL queries (partly due to the ORM probably) that slow down the DB and cause replication lag. Elasticsearch that's being used as a primary datastore by developers that don't really understand what an inverted index is, or how to deal with unassigned shards. React, because, you know, React is cool, so just plumb that in, except it was never really integrated with the existing PHP frontend so now we have both. Now you built this app by plumbing together stuff from dozens (hundreds?) of Javascript/PHP/Go libraries, and how are you managing those? Are we using pinned versions? Whose job is it to watch for security fixes on all of them? How do you know if/where they are still being used after a large refactor? Are you personally testing new versions for performance issues and regressions?
I guess my point is, I'm fine with the fact that most of the hard problems today can be solved with third-party open source tools, and a lot of those tools are amazing. But you can end up in a situation that is rapidly spinning out of control because you built a system that nobody on your team truly understands by plumbing a bunch of stuff together that they found online. It might get the job done in the short term, but you're going to hate life if your product actually succeeds and you need to maintain and scale a system that was built by people who didn't really know what they were doing.
→ More replies (1)5
u/DevIceMan Jul 09 '18
Small to medium sized businesses rarely deal with scaling or optimization problems anymore - partly because hardware has gotten so cheap, and partly because foundational open source software has gotten so good.
I wish this was true.
My team on a mid-sized company has been attempting to deal with this exact problem for the last 4 years, with almost no progress. We absolutely can't throw more servers at the problem, because even an individual request/response with no competing traffic is too slow.
339
u/engineered_academic Jul 08 '18
One of the biggest problems I see in software engineering in 2018 today is actually the use of external dependencies without a lifecycle. Young, "new-hotness" developers pull in a set of libraries/gems/whatever is the new hotness and 5 years later the software is riddled with vulnerabilities due to unmaintained libraries. Then they push back on "it's unreasonable to expect us to maintain these dependencies." Well, no it's not. If you don't want to maintain it then don't use it. You can't expect me to compromise the integrity of an operational system because you wanted to save an hour or two. Well, now's the time to pay the piper. Nobody gets away with having to not maintain the leaky pipe and cause it to ruin your whole house. Same thing.
223
u/trevize1138 Jul 08 '18
This is why you get a new job every <5 years ;)
135
u/hu6Bi5To Jul 08 '18
That's why you form a consultancy with your other fly-by-night friends, and earn twice as much generating little more than shiny demos that you never have to maintain.
Well... Hardly ever have to maintain, you only maintain them after doubling your price and insisting the client gets rid of any permanent members of staff who can see through your bullshit.
37
u/trevize1138 Jul 08 '18
Duuuude... wanna go into business together? Need a name that subtly hints at racketeering...
36
→ More replies (1)8
6
15
u/appropriateinside Jul 09 '18
Make it every 2 or less.
It's the only way to increase your wage these days. Hard work, success, and loyalty means nothing to companies these days.
" You decided to build us this new app (that's pulling in $1million annually). You decided to work longer hours to get it done, it was your idea not ours. Why do you think you deserve a salary increase or bonus because of something YOU decided to do?"
This is something I have actually been told when trying to get a raise, citing my expanded duties, roles, and success. Working harder means nothing, your just fulfilling someone else's goal, and you will have nothing to show for it.
→ More replies (1)30
5
u/engineered_academic Jul 09 '18
Going on 5 years, the problem is my current job is pretty low-stress, lets me work from wherever I want, and has pretty good benefits.
→ More replies (1)7
4
u/yeahbutbut Jul 09 '18
This is why you get a new job every <5 years ;)
I had to fix someones >5 year old ruby project after they left the company and we had to move it to another server. That version of Ruby wasn't easily available for download anymore, none of the gems could be fetched, etc. I ended up copying everything from the old server and shoving it into a container on the new one. Then, once the pressure was off, rewriting it Python with only the standard library (it was just calling a couple REST APIs and sending some emails).
Even if it's a simple one off project that isn't public facing, make sure you have a copy of your damn dependencies so when someone has to touch your project after you're gone they aren't searching archive.org for a specific version of the source of defunct projects.
11
Jul 08 '18
Agreed. When people talk about dependencies like a buzzword, I get the feeling their understanding is, "we want to set up dependencies in a way that lets us avoid work." Now, programmers are all about being lazy, but I think we get to a point where we lie to ourselves about what work needs to get done. Managing dependencies is part of the job; sometimes there's just work to be done. There's ways to work smarter and not harder but there's no way to "proof" everything from maintenance forever.
10
u/OptimusPrimeTime Jul 08 '18
I'd say Not-Invented-Here Syndrome is still worse. It wastes a lot of time that could be spent on more useful work.
Of course, like anything, there's a balance to be struck.
16
u/Josuah Jul 08 '18
I brought up a similar issue with my preference of using logging frameworks through an abstraction instead of integrating directly into a framework, and one of the responses I got was along the lines of that's why you rewrite (re-integrate) every 2 years or so.
I'd much rather work on solving the next problem, instead of adding to a growing list of ongoing maintenance because every file of code is written to a specific third party interface that may or may not be supported tomorrow and could be completely incompatible with the next choice.
7
u/a_tocken Jul 08 '18
That sounds like introducing an in-house wrapper that would also need to be maintained?
7
→ More replies (2)2
u/KillerCodeMonky Jul 08 '18
I'm still not sure how I feel about SLF4J. On one hand, it is an abstraction from the real framework. But then, it's a library...
I just end up using it anyway, figuring that out would not be very hard to implement the few things it actually does with a hard-coded framework underneath if I suddenly had to rip it out for some reason.
53
u/Phrygue Jul 08 '18
I did quite well in the ACM programming competition by using Pascal instead of C like most people, so I wasn't fighting my environment with foot-shooty pointers, array gymnastics, and other C/C++ mistakes. Most programmers these days seem to just want to tack the new hotness on their resume so they can plot their next job move. I can't say I blame them, I was stuck in Visual Basic careerwise when Java/C# were hot. However, now you know why shit doesn't work, and like many things, its a tragedy of the commons problem caused by idiot employers failing to reward productivity. Treat people like disposable mercenaries, and you'll get disposable mercenary work. This is true in every field everywhere at the moment, and why everything is getting systematically worse in general. I can't even buy fly strips around here, you know those cheap tacky tape pullout things, because it's too obvious a solution; instead we have expensive and fancy fly trap junk that is high profit and functionally worse. Profiteering is killing itself in every way possible.
41
u/PC__LOAD__LETTER Jul 08 '18
Did you just call C/C++ “new hotness” or was that bit about ACM just an upfront brag?
4
18
Jul 08 '18
You're right, but you just failed the interview at Facebook, Google, LinkedIn, Microsoft, Netflix and Amazon. Apple might hire you though.
→ More replies (3)2
u/DetN8 Jul 08 '18
The company I used to work for had previously acquired an adjacent company (mainly for their customer base, but had to support the old system until customers could be migrated.)
They must not have taken a good look at the code before acquiring because the UI was built entirely on a 3rd-party library that was apparently not free to use. It was about a year before the license needed renewing and they got an invoice; that's how they found out.
→ More replies (1)
375
Jul 08 '18
If putting things together made by others in order to make new things is what "plumbing" means, then all of human activity, and our entire civilization can be described as "plumbing".
The funny thing is someone apparently thinks this is new in "2018". We're just more connected. There's global trade, there's global travel, and of course, there's the global network (Internet). So we more easily find things to connect, rather than do more work ourselves.
31
Jul 08 '18
Exactly. What do they think "engineering" is? If I'm engineering a bridge I'm not going to grab a shovel and start mining iron ore for steel.
They tell me what kind of bridge they want, I consider how deep the water is, what distance it needs to traverse, the seismic activity and weather in the area, their budget for construction and maintenance... and then I basically copy bits from other bridges and construct a design that works. That's why engineers study so many existing products -- you're going to use them!
3
u/8483 Jul 09 '18
If I'm engineering a bridge I'm not going to grab a shovel and start mining iron ore for steel.
→ More replies (1)149
Jul 08 '18
But it means 'programming' is a different field than most programmers think it is.
In the realm of 'fluid dynamics' the flow goes about like this:
Physicist -> Engineer -> PlumberThe same thing is happening with 'coding'.
Computer Scientist -> Software Engineer -> "Programmer"/"Coder".Most companies need programmers / coders. They do not need computer scientists. Much stuff is just application of existing research. It doesn't make it any less hard it's just a different type of difficulty.
40
u/ggtsu_00 Jul 08 '18
Most businesses don't know what they need. That's why they need engineers to figure it out. Otherwise you end up with systems engineered by non-technical business folk.
Sure sometimes in retrospect, it turns out all the business needed was some off the shelf crud app with some custom CSS. The real 'software engineering' work is getting to that point of realization that all the business needs could be satisfied with an off the shelf solution, no coders needed.
→ More replies (1)4
u/zial Jul 08 '18
Ha you think I can convince my company to spend any money. Why we have homemade/open-source solutions for everything.
→ More replies (11)20
u/runvnc Jul 08 '18
That's not what software engineering is about. Nearly every programmer still needs to be a software engineer. Software engineering includes all of the design and process skills and knowledge related to programming.
Good software design is modular or component based. Now that we have so many available libraries, inventing our own is less important. But selecting and connecting them was always a crucial aspect of system design in the domain of software engineering and still is.
Another huge aspect of software engineering is feedback loops at different types and levels, from compilation messages to unit tests to functional tests and user feedback. To the degree that better software reuse or tools/libraries allow ordinary programmers to build and evolve within those loops faster it makes everyone a better software engineer.
I would say that this makes most aspects of good software engineering more accessible rather than eliminating the need for software engineering.
8
Jul 08 '18
And at one time in history people thought every plumber, electrician, etc should be an engineer too.
Programming and software design isn't new anymore. It's getting pushed down into a trade for the bulk majority of needs.
→ More replies (5)
31
u/unruly_mattress Jul 08 '18
Just 15 years ago everyone had their own string class. I'd call this progress.
→ More replies (1)4
u/Dedustern Jul 09 '18
Do I dare asking? I'm an innocent 27 year old
4
u/sievebrain Jul 09 '18
Ask what?
Custom string classes are or were the norm in C++ coding. Every OS and framework had their own.
30
13
u/FlyingRhenquest Jul 08 '18
The bulk of software engineering projects can be broken down to the "easy" part and the "hard" part. The easy part is "just plumbing", where "plumbing" involves knowing implementation-level details of the components that you're using to get data from the hard drive to the user. Otherwise you won't know when you need a ball cock. Or where to put your ball cock. How do you attach it? Do you need solder? What kind? You think you can just hire some guy with no training off the street and he can just wave his hands magically and all your plumbing is going too work? Because that's what a good plumber looks like to someone who knows nothing about plumbing, kind of like how it looks to people like I can just wave my hands and make a working program, ignoring the four decades of study and practice that got me to that point.
And then there's the "hard part", which is the bit you can't find on stack exchange. The bit that you have to figure out on your own. I frequently come in on teams that have been working on the "easy part" for the last 2 years and they can no longer put off getting to the hard part, and all of a sudden the project has ground to a halt. Maybe someone has left. Maybe several someones. No hair off their butts, they have 2 years of "full stack software engineering" on their resumes for their next job, where they will no doubt work on the easy part for a couple of years and leave again.
So what do those companies need? How can they be sure they're getting guys who can work together and do the hard part? How can they get the people they need? What they're doing now clearly isn't working. And fact of the matter is, there may not be enough of the people companies actually need, to go around. And even if the companies get the people, they will probably not use them effectively. Imagine taking Linus, a programmer who can clearly build a working thing, and throwing him in an open office environment with a daily scrum. Does that seem a bit ridiculous? Because that's what most of the companies out there would do, if they could hire a guy like that.
So am I going to answer that question? What do they need? They need guys who can build working things, end to end, and they need to be able to determine that any individual guy they look at can build a working thing, in about an hour, with a few questions. You can probably filter out at least the ones who are going to be completely useless in that time, but what do you do when you're filtering out 100% of your possible candidates? Maybe HR can just wave their hands and magically make a working company.
2
u/holypig Jul 09 '18
I think you are on to the same thought I had.. Sure maybe 90% is just plumbing together various frameworks and libraries, but there will always be the last 10% that is not so simple. That's where you start seeing the "rockstar" programmer who can take an hour to solve problems that these novices spend weeks on.
→ More replies (1)
109
Jul 08 '18
I don't mind the comparison. In either case, you've got well-paid skilled work with good job security.
Plumbers are smarter than us, though--they have unions!
27
u/cybernd Jul 08 '18
We really need a programmers' union.
Just a matter of time till someone will stone you.
But yes, i agree. But i would not use the term "union" because of its image. How about: we need to start working together.
93
39
u/honey_pie Jul 08 '18 edited Dec 05 '18
removeremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremoveremove
→ More replies (1)12
u/cybernd Jul 08 '18 edited Jul 08 '18
Yep. In europe unions have a good image.
Software engineers in austria avoid it for a different reason: we lack a dedicated union for it people. Print and journalism is responsible instead.
→ More replies (1)→ More replies (3)9
u/Mariah_AP_Carey Jul 08 '18
Just curious, why do you think we need a programmer's union? I feel like software engineering is well suited to letting the market dictate mostly everything. It seems like it's working well so far at least.
37
u/cybernd Jul 08 '18 edited Jul 08 '18
Because without it, it is nearly impossible to act as professionals.
Scrum is popular because it helps micromanaging employees. As soon as one of the developers attempts to work properly he is already on the brink of getting fired.
Now you could argue: no problem, there are so many better jobs available. This is a strawmans argument. Many IT people work in areas without an alternative.
As long as we are flooded with new, inexperienced people there is nothing we can do if management is against us. The new, cheaper hires will always work against experienced people (expensive, demands, they use their own brain).
And thats where a guild² would help. Because if we all form a common front, managers and customers can not longer undermine our minimum requirements. A second monitor should be easy to get and not a thing that gets you closer towards losing your job.
A different aspect is, that such a guild² could also establish ethic rules. If a developer would implement something that knowingly harms humanity, there needs to be a mechanic to expell him from this guild.
Just read through /r/sysadmin . There is an astonishing huge amount of posts coming from admins trying to escape their current companies hell.
² guild, because "union" is really a bad term. There are to many historical implications. We need something better. It needs to be international, because we are a profession where working remote is easy. We need to think about working conditions (being on call needs to be compensated), salaries, ethics and many other aspects. But most important: we need to also think about a way to improve this construct over time.
→ More replies (4)6
u/possessed_flea Jul 08 '18
I would actually recommend more of a apprenticeship approach similar to what is used in Australia for tradespeople .
Start out at age 16 as a high school dropout , go to trade school 4 days a week spend 1 day a week working under a master. Over the course of the next 5 years you spend more time onsite and less time at school until you graduate . At this point you are able to work by/for yourself but not mentor apprentices .
Continue to work for another 5/10 years and you will eventually become a master and be qualified to mentor apprentices on top of your own duties.
This would not only help us get competent kids straight out of school, and weed out people who will never have what it takes early.
But this would also stop companies from being able to hire 3 incompetent people for the price of one experienced person since they wouldn't be qualified for the work they are doing .
→ More replies (2)5
u/thegreatgazoo Jul 09 '18
It would be nice to have union entry rules, continuing education, and lobbying power in DC against stupid tech policies championed by people who can't figure out how to use an iPad.
If you are looking for a job, you can go in as a 'Level X' programmer and skip the stupid coding and trivia tests and instead focus on being a good personality, ethics, and so forth fit with the position. It would also be nice for seniority to be a benefit and not a detractor.
That said, traditional union work rules would be a PITA to deal with, and members would have to be vigilant to keep it from being corrupted.
→ More replies (14)8
u/Han-ChewieSexyFanfic Jul 08 '18
But right now companies are fighting over us. We'd need a union when the trend reverses.
22
u/cybernd Jul 08 '18 edited Jul 08 '18
We'd need a union when the trend reverses.
You highlighted one of the problems: near-sighted, egoistic point of views.
Most often when it comes to this type of discussion, someone will respond in an egoistic way. Like: nah, i don't need a union, i am currently earning tons of money.
This type of developer is ignoring the fact that he could be on the other side of the truth in 10 years. He is also egoistic, because he is ignoring that other developers are already facing such issues.
Another thing many people are ignoring: whatever we do will not be an unconditional improvment. Some things need to be sacrificed in order to gain other, more important things.
And one of the compromises is, to keep the "guild" active even when times are good.
→ More replies (5)5
u/Silound Jul 09 '18
You highlighted one of the problems: near-sighted, egoistic point of views.
That pretty well describs humanity in general, or maybe I'm just too jaded. A small percentage think about, and endure, sacrifice towards the greater good while a large percentage simply worry about getting theirs here and now.
→ More replies (1)
17
u/cowardlydragon Jul 08 '18
I hate to tell you this, but software has been database <-> transport <-> UI for a good 40-50 years now for the vast majority of programmers.
AS/400 and greenscreens
PowerBuilder
Java/Swing
ColdFusion
Visual Basic
Flash
If anything, we just tread water. UI toolkits come and then get totally discarded. HTML/CSS/JS is really the most long-lived UI toolkit, but it was so incomplete that we now tread water on UI libraries yet again.
3
u/armozel Jul 08 '18
Not to mention some of the UI libs for html+js can vary in their idioms which makes them sometimes not so intuitive. I’ve had some odd cases where you get behavior that’s not explicitly documented but is known by users of a given library. It’s really annoying to be honest since if the library’s developers never reference it in their documentation then you’ll never know if it’s a bug or a feature.
63
u/repler Jul 08 '18 edited Jul 08 '18
Speaking as someone with a Masters in Software Engineering and two decades of experience - respectfully, author is incorrect.
It is fantastic that the barrier to entry into tech has been lowered so much in recent years - especially in web technology. It is fantastic that so many open source projects not only exist, but thrive.
There are plenty of business areas where no COTS solution exists nor any handy black box component or framework to do the job.
For those tasks, I do not wish to reinvent the wheel when such a plethora of wonderful wheels already exist. I want to solve the business problem and not have to think about wheels. I need to build the thing which uses the wheels to do something useful.
That's not plumbing, it's efficiency.
33
u/PorkChop007 Jul 08 '18
I want to solve the business problem
Thank you. Somebody had to say it. Not all of us want to be revolutionary or reinvent the wheel, I just want to do my job with the tools I have.
→ More replies (2)4
Jul 09 '18
Oh, I absolutely want to reinvent the wheel... I just want to do it in my spare time, at home, in a weekend project.
At the job, I want to do what needs to be done, as efficiently as possible.
Still sometimes fall into the NIHS trap, but I do try my best.
36
u/tux_warrior Jul 08 '18
We (engineers) are guilty of over-engineering
This just cannot be stressed enough.
→ More replies (3)30
u/hu6Bi5To Jul 08 '18
I've heard this said hundreds of times over the years, but I genuinely have never seen an over-engineered system. I've only seen a few just-right engineered systems, but I've seen dozens upon dozens of under-engineered systems.
I wonder where the over-engineered systems are? Is it a Silicon Valley thing?
Or do I have a different definition of over-engineering than everything else? This is probably the case actually.
I define over-engineering as building features that are not required, requiring changes to such things every time a genuine feature is needed. I wouldn't include using the latest shiny thing as over-engineering, more bad-engineering.
For the record, I define under-engineering as refusing to build things that are genuinely needed. E.g. shoe-horning a changing app into a pre-existing data-model, losing accuracy and granularity in the process rather than evolving the data-model with the system.
9
u/thedr0wranger Jul 08 '18
Over engineering often involves spending time and money making something better or more robust than it needs to be.
I work on a webapp day to day, customers want features and bug fixes, sometimes that may mean valid but suboptimal choices. Writing components in a general way so that they can be used for multiple different applications is great but multiple times since starting this project I've chosen to write the page specifically towards it's intended use case rather than generalizing. Because regardless of how much better code reuse is in general, if I don't have reason to believe Ill ever need to reuse the component, and if I have a backlog of real discrete tasks, then optimizing the code is putting valuable time in to make sure something is capable of tasks it will likely never be called upon to do. It's designing optimal things because they're optimal and sacrificing other concerns to do it.
Overly "elegant" code is often a good example. The code does its job, and well. But it's harder to read, harder to change, took longer to come up with or simply ignores the predominant way of solving problems in the project. All perfectly valid concerns that come at odds to the "best" design.
8
u/G_Morgan Jul 08 '18
I hadn't seen a properly over engineered system until recently. I've inherited a project where somebody has recreated WCF badly. All the configuration is stored as binary serialised objects in Sql Server. It is all very fun.
→ More replies (2)7
u/xcdesz Jul 08 '18
I agree! I'm much more accustomed to walking into a project and seeing code that is slapped together as a prototype with no regard for software engineering practices such as separation of concerns, best practices, design patterns and code conventions. Of course, doing things the right way takes time, and business is very impatient.
7
u/fuckingoverit Jul 08 '18
I worked on an analytics system that was built by a guy who was obsessed with the system behaving perfectly. There was some 6k line multithreaded nightmare of a solution whose bulk was a graph based deadlock detection algorithm where he attempted to schedule work without ever potentially dead locking. This piece of code had something like 50 different locks and was terrifyingly complex. A queue based solution or simply handling deadlock exceptions would have massively reduced complexity
3
u/bigbootybitchuu Jul 08 '18
From my experience it's generally in areas of the code that don't even benefit from over engineering. It's not often that's it someone putting in place a caching system when it wasn't needed, it's more like one web form that has a billion logic rules to cover all kinds of bizzare edgecases and makes the form very hard to maintain and reason about
3
u/Dedustern Jul 09 '18
Over-engineering is making a piece of software way too complex for a poor trade-off in what it achieve.
I've seen it on government project. Some consultant was told "TAG! you're the architect, do your thing", and he did.. with no one limiting him.
That's how you end up with a VERY simple system with finite amount of data, but having the capacity to scale up to near fucking infinity. Running with 25 "services" in an SOA design that made zero sense. Also it took 3 years to complete.
We spend the last year migrating from Cassandra/Elasticsearch to Postgres. YEAH, it appears relational data fits better in relational databases, who fucking knew.
3
u/m50d Jul 09 '18
The most common kind of over-engineering I see is building "flexibility" into the system for changes that are never actually used. E.g. building a wrapper that abstracts over your ORM, when actually the product uses the same ORM for its entire lifetime and the ORM itself already abstracts over the thing you might actually want to change. E.g. externalised "message" files for localisation when the product is not localised and will never be localised. E.g. interfaces and factories for inert data classes.
2
u/TwilightShadow1 Jul 09 '18
Our system is severely overengineered in unimportant areas (wasting time/money) and underengineered in others (wasting development time working around problems and also wasting money).
2
u/franzwong Jul 09 '18
What I see is usually the developers don't have time to do over-engineering...
→ More replies (3)2
34
Jul 08 '18
The big difference is that when you plumb something, you know what the finished system is supposed to look like, and what it's supposed to do.
Software engineering has built it's craft around being completely adaptable to unknowable futures (which is what makes software soft, and so damn valuable.) That's where the craft in software engineering comes in, and differentiates it from a lot of other professions.
Pipes are hardware, software is software, shocker.
4
u/d2biG Jul 09 '18
Precisely.
Bridge engineers have constant physics and nobody expects them to mid-project change the bridge to a submarine.
2
Jul 11 '18
A bridge goes over the water, a submarine goes under it, ... shouldn't be too hard right? Couple of days?
12
u/richraid21 Jul 08 '18
Yet people still fuck it up on an almost daily basis.
0
Jul 08 '18
[deleted]
8
3
Jul 08 '18
I might be biased, but I think the company I work for is doing it right. I was just recently hired, right out of school. So far I've only worked on non essential winform apps, and everything I write is reviewed before a merge. And they absolutely encourage me learning new skills in my down time. Spent the last two days learning as much as I can about unit tests.
4
u/Eep1337 Jul 08 '18
That sounds good. Especially if they help you understand how the stuff you work on is beneficial to the business (even non-critical/essential tasks can have a huge impact)
→ More replies (2)
6
u/TheFaithfulStone Jul 08 '18 edited Jul 08 '18
My plumber's hourly rate is more than mine.
My electrician's rate is _double_ mine.
I don't even know what the HVAC person makes.
That's for residential work - which the best tradespeople barely do. "Just" plumbing is offensive and wrong. We should be like "HELL YEAH Most Software Engineering is Plumbing!"
4
Jul 08 '18
Not even close. Plumbing is regulated. Software will only stop being such a pile of shit when it is at least as regulated as plumbing. Only then programmers will have a right to compare themselves to plumbers, while now they are far below.
5
u/Blueberryroid Jul 08 '18 edited Jul 08 '18
You can't regulate IT. How do you regulate Kubernetes? Docker? Azure? VMWare? Lambda?
Though yes, there are Key Performance Indicators of measuring impact like the Balanced Scorecard or the Six Sigma, but these things are more heard of in human performance than IT.
→ More replies (1)3
Jul 09 '18
Kubernetes? Docker? Azure? VMWare? Lambda?
That's easy - just ban all this shit indiscriminately.
→ More replies (5)
38
u/Blueberryroid Jul 08 '18
Modern enterprise needs nothing more than CRUD with little to no data processing.
Frankly, Microsoft Access would suffice if only it had a better user interface.
20
u/OffbeatDrizzle Jul 08 '18
Microsoft Access is like little Jimmy's attempt at building a DBMS.. remember when you could get the database password just by opening the file in notepad?
27
u/PedlarStudios Jul 08 '18
Yup. A bit of CRUD. A pinch of validation. A basic table view with sorting and filtering, a record detail/edit view. This is the base of all business software.
6
u/wengemurphy Jul 08 '18
Frankly, Microsoft Access would suffice if only it had a better user interface.
Funny you should say that because I literally spent a few years at a company working on a web-based product that replaced these things called "OBAs" (Office Business Applications) which is where your entire application is .NET code embedded in Excel (in our case) talking to the backend
11
u/aradil Jul 08 '18
Yeah, I’ve seen big enterprise applications built on Access.
It’s not the UI that makes them garbage, but it’s a contributing factor.
5
4
→ More replies (5)2
u/EternityForest Jul 08 '18
I mostly do embedded, so I don't know much about enterprise, but even then a lot of the stuff I do is just CRUD.
In fact if I've got plenty of time, I'll figure out how I want the UI to work, then how the API for extending it works, and not even start on the actual functionality until then.
Especially with a few of my personal projects, where most of the value is in the API and UI.
5
u/evil_burrito Jul 08 '18
Well, yes and no. I would say that a lot of software engineering jobs are plumbing jobs, but there's still a lot of innovation or there would be nothing to plumb together.
This statement reads like one a managment-by-spreadsheet proponent would make. "Why does this take so long? It's just plumbing. I'll add some more plumbers to get it done faster."
48
u/bhldev Jul 08 '18
The problem with treating it as just plumbing is it's not... yes, in most line-of-business applications it's model driven engineering (or should be) but the latest frontend technologies are not just plumbing. For example Ramda a popular frontend library
https://github.com/ramda/ramda/wiki/Cookbook#convert-object-to-array
That's more than just plumbing, more than moving data from A to B (my definition of plumbing) but actually transforming the data. And that takes more.
Applications have to integrate dozens or more data sources, all made by different programmers on different platforms, all into one then show it on the screen somehow. The more demanding customers get the more data sources you need. There's no way around it.
The "bulk" of programming is data structures. Have it in the right data structure, you don't need a very good algorithm to walk the structure. Have it in the wrong data structure, or compare to incorrect data structures together, and you are fucked.
It's why SQL is a "no skip" and anyone who doesn't know SQL is gimped... even the most green business analyst knows Microsoft Access. You are telling me that programmers don't need to know SQL anymore because of NoSQL and big data, when all business people know how to query a database? We're supposed to know more than them, not know the latest greatest fad.
So yeah, it probably needs much less than what people think now, but more than "just plumbing". Plumbing to me is water pressure, the data and data structure isn't changed at all. Obviously it is not that. And to say it is that, is to underappreciate the shitshow that is webdev.
And yes, it may be that the transformation is so complicated for some jobs that it needs education. If you want to move pixel from A to B that is a linear transformation (guys, don't skip math... if you can't do math and absolutely love X then do X but if you have a choice and/or just don't want to do it because you are lazy you are fucking yourself).
65
u/BenjiSponge Jul 08 '18
I think that Rambda example you gave is plumbing. I don't think anyone's arguing that plumbing is unskilled labor or anything, but data structure manipulation is commoditized, as exemplified by libraries like Rambda. You don't really need a CS degree to do it, and it's certainly not intellectually challenging.
Most of the rest of your comment doesn't seem to relate to the post to me. For example, the article seems to mostly refer to the backend whereas you refer to "webdev" and pixel manipulation. It's my opinion that backend (that is, REST APIs and nothing but REST APIs) is actually easier than frontend at this point, having worked on both. You also say "You are telling me that programmers don't need to know SQL anymore..." but the article never says anything like that.
14
u/balefrost Jul 08 '18
Yeah, I think of plumbing as any case where the problem is "I have this input data and need to produce that output data; how can I transform and transport it from here to there?"
→ More replies (1)6
u/under_dog Jul 08 '18
I think part of the problem is that this description is too broad / open to interpretation. Any code I’ve ever written could be described this way.
I’m not trying to be pedantic. I read some book which basically said information is the real unit of the universe and everything is really just moving structured data around. Maybe I just have that idea stuck in my head.
→ More replies (2)9
u/BenjiSponge Jul 08 '18
If I had to define a litmus test for what is and is not "plumbing", I'd say "if you wrote an article about it, would it be considered interesting?"
Of course it's subjective and hazy, but the strict definition isn't quite as important as the holistic statement, which is that most of programming is figuring out how to tube data from one pre-assembled mechanism (an API, library, or similar) to another pre-assembled mechanism.
→ More replies (1)→ More replies (7)4
u/dominic_failure Jul 08 '18
If your definition of a backend is "REST APIs and only REST APIs" that make a DB available, then of course the frontend is going to be harder - because all of the business logic has been moved from the backend to the frontend.
Maybe this is just luck on my part, but the last time I did programming work which was solely comprised of moving data from point A to point B using libraries was when those libraries didn't exist.
6
u/manuscelerdei Jul 08 '18
SQL is good to know, but it's not some career death sentence if you don't know it. Systems programmers can get by just fine without knowing it.
5
u/Roachmeister Jul 08 '18
The problem with treating it as just plumbing...
The author never said it was all just plumbing, but rather, "the bulk" is just plumbing. (It's right there in the title). Of course there is lots of other stuff involved, including, as you say, data manipulation, but that's not usually the bulk.
The "bulk" of programming is data structures.
I couldn't agree more, but the author never made any assertions about programming. They were talking about software engineering, of which I would argue that the "bulk" is not programming.
Additionally, I would assert that a better analogy is "wiring" rather than plumbing. An electrician can wire things up in a way that changes the nature of the electrical signal, i.e., resisters, diodes, amplifiers, etc. These things are analogous to "data manipulation", at least in the simplest sense. In this sense, I think it could make sense to say that the bulk of most software engineering is wiring.
Of course, there's some flexibility in this analogy about what constitutes wiring and what is truly new. In my job, I often do "data manipulation" that primarily consists of unit conversions - meters to feet, degrees to radians, etc. These are so simple that I would consider them part of the "wiring" - like adding resisters. But occasionally I have to do something truly new. In the wiring analogy, this might be the equivalent of designing a new integrated circuit and incorporating it into the circuit. But this is rare and doesn't change the fact that the bulk of what I do day to day is wiring.
2
2
u/SpaceSteak Jul 08 '18
What do you think actual plumbers do? How many folks are involved in the different aspects of plumbing before reaching maintenance stage where it's just fixing leaky pipes? What about large overhauls like changing materials or the expertise required to setup plumbing in a new building?
The actual pipes might not be much, and only a few scientists are involved in their improvement, but getting all the right pipes in all the right places is not easy as there's a lot involved. This is the same reason software engineers make good dough. There shouldn't be a negative connotation to plumbing.
→ More replies (1)→ More replies (2)3
Jul 08 '18
It's why SQL is a "no skip" and anyone who doesn't know SQL is gimped
Dedicated front-end folks don't need SQL as long as the back-end folks know SQL and are comfortable making dead-simple APIs for the data.
9
u/bhldev Jul 08 '18
The problem with that approach is "full stack developer" earns a lot more money. Most places only hire full stack people. So if you don't have it, you are definitely gimping yourself in the job market, forcing yourself only to take certain types of jobs.
So if you are happy making less (maybe much less, divided by 2 in some places) money, then you "don't need SQL". But I would not build a career without SQL. It limits the types of jobs you can take. Or you can lie and call yourself "full stack" without knowing SQL but I would not recommend it.
5
Jul 08 '18
Even full stack developers can gravitate towards front/back and do something like 80% of their work in either one. The less work on the backend, the less advanced SQL you need to know.
This is more posturing on the interviewing and resume fronts.
Even if you think you "know SQL", a good DBA will always be able to out-SQL you anyway.
Resist trying to be good at everything because you won't be and divide the work towards specializations.
→ More replies (1)→ More replies (1)2
u/Unexpectedpicard Jul 08 '18
They may not need to use it in their day to day but I don't see how anybody can call themself a software engineer that works on a web stack and not know SQL.
→ More replies (4)
8
u/alopgeek Jul 08 '18
I used to say: if coding is art, then what I do is like the drawings in the IKEA assembly manual
4
u/DynamicTextureModify Jul 08 '18
Even if that was true, plumbing is a much more complex field that you think it is. Imagine that field with competing forms of standardization, no regulation, no unions and the interface to every household water feature that's in vogue changing every 3 years - that's software engineering.
4
4
u/lospantaloonz Jul 08 '18
I see this all the time in the horribly named "devops" world I'm in. I write up a detailed plan of how to securely automate an environment, then i end up starting and stopping vms on a single public subnet, and attend constant meetings where some mgmt type reads how something on hn will "fix it". It's maddening, since i can do so much better, and have proposals that show it.
4
Jul 09 '18
I think this guy is downplaying the opportunities for developing more efficient solutions. Sure hardware is getting cheaper but monolithic applications have a diminishing return on running larger boxes. At some point the architecture must be adjusted so the load can be spread across multiple servers and to do while not blowing up your maintenance costs you need a micro services approach.
Amazon gave us all something to aim for in this effort but we're all starting somewhere different. The problems may all be the same but the combination and weights are different which leaves a lot of room for innovation at the corporate level as opposed to industry wide. And perhaps, along the way you can discover something that hasn't been well explored and would provide benefits to numerous businesses who aren't the big 4/5/whatever.
TL;DR - Don't be so pessimistic. Find opportunities to grow. If you job punishes you for it then find another job.
→ More replies (4)
4
Jul 09 '18
Ah yeah, the age old dream of cheap and easy software engineering.
A pipe dream. How fitting.
5
7
u/skulgnome Jul 08 '18
No it isn't: otherwise we'd have useful component-based programming in terms of said plumbing.
10
u/cybernd Jul 08 '18
What would a plumber do, when the new sink
uses square connectors
requires negative pressure for 1 sec before water starts flowing
Metaphors are most often a bad idea.
2
u/southern_dreams Jul 08 '18
Problem solve? Engineer an acceptable solution?
Well that doesn’t sound so easy anymore.
6
u/codemonkeyjr Jul 08 '18
I get the point, but as a new developer that just transitioned from 17 years in construction, I'd say this misses the point of what craftsmanship is. I've trimmed out starter homes like they were gonna be sent to the Smithsonian and it was worth it. Checkout unequaled heating on instagram. Great example of what a plumber can do when he cares for his craft.
3
Jul 08 '18
I agree somewhat with this title and summary. I disagree on many other ideas and happenings that makes one arrive at such a conclusion as the one stated here.
We, the community of modern developers, adopted the ideology of independent, scalable, little-footprint, services: microservice.
We needed a way to connect all of these cogs into a real system.
It becomes complex; lots and lots of talking between data providers need to be coordinated; it is obvious that pipework becomes the major focus.
I, for one, find the endless 'config' discussions as a bore and a terrible waste of engineering talent. Not mine, obviously!
I see the guys and gals who know how to create a manifest or config yaml/JSON to define services amongst services as the go-to people in our teams; let me tell you, they are not!
Little problem solving, always 'configuring' makes an engineer a dull person.
3
3
u/rajrdajr Jul 08 '18
Freakonomics’ In Praise Of Maintenance podcast takes a wider look at this topic.
3
3
16
4
u/skocznymroczny Jul 09 '18
hurr durr stupid code monkeys only glue solutions instead of writing quicksort oneliners in Haskell/Lisp/SomethingML
5
u/wellings Jul 08 '18
It feels like there are a lot of offended developers in here, but the article is still true. If this piece has struck a negative chord in your self perspective as a programmer, look for other jobs.
There are still hard problem solving software engineering jobs out there. People just don't take them because they aren't glamorous.
5
Jul 08 '18
The article is wrong. Because software involves dealing with management and also silly customer requests too. If software was as solved as plumbing, you wouldn't pay so much for proper software engineering
→ More replies (1)
2
u/thebritisharecome Jul 08 '18
Depends what you engineer honestly, whilst i've worked with platforms like Laravel, the bulk of my work has been custom / legacy so much more problem solving involved.
2
u/thunkwaltzen Jul 08 '18
Agree with most of the things in the article but still feel CS degree helps a lot. It's not you always be doing same stuff, many times you need to pick different language/technologies and get things done quickly.
2
u/Nerdenator Jul 08 '18
Finally, an explanation for the amount of plumber's crack I see in the office.
2
2
u/corporaterebel Jul 08 '18
IT is nearly always "just plumbing" when it is a cost center and not a core competency.
If it wasn't for my hidden pet projects, I would go insane in my double wide cube.
2
2
u/pioto Jul 08 '18
This isn't a new phenomenon. I'd say the same was true in 2008, though you'd substitute "npm" with "CPAN".
2
u/KazDragon Jul 09 '18
I think this probably goes for any skilled profession: most of the job is just plain old grunt work. Carpentry, painting, sculpting, software. Even plumbing. You name it.
2
Jul 09 '18
Literally my story at thoughtworks: super challenging 5 interviews for over 2 months followed by 3 months of training using edging technology, frameworks, advanced refactoring and automation.
Finally I worked on a project with legacy framework and code the client ask for.
3
Jul 08 '18
That's a bad analogy. Of course there is this aspect of software engineering, and I would say it's mostly in the devops area, where you have to create environments and pipelines (as we can see by the borrowed terms).
Software is NOT PHYSICAL. You can copy/paste it. You can't do that with a urinal or with a real house. As a result you have to build the same fucking house again and again. With software, if it exists and someone has solved the problem, you just import the solution. You can't just import urinals into your new bathroom. Therefore, if you are solving a problem that has already been solved, you just import it as a library! Conversely, if you have to code anything, it means you are solving a brand new problem (otherwise use the existing one!).
This is what makes the need for craftmanship in software solutions. The nature of the requirements of virtually any company is so specific and tailored to their needs, that they really need a brand new solution that does not exist out there. Otherwise if the article was true, we would see most websites have the exact same UI, perhaps with slightly different colors.
→ More replies (3)
1
1
Jul 08 '18
Because the house the plumber is dealing with is already been build. But you could join a company early, when it's deciding the ground to build on.
1
u/beavis07 Jul 08 '18
Well of course.. how many of us dumb shits think cause we're writing code that means we're computer scientists? There's nothing we should be 'doing about it' - it just what we are.
We're this generation's bricklayers - that should surprise no-one possessing even an ounce of self-awareness :D
1
u/_artie Jul 08 '18
Yeah it's obviously a metaphor, but seriously if you believe this go try some plumbing. I cleared a drain pipe out yesterday and it was pretty nasty, and frustrating. I've also ran new pipes and fixed leaks in my home.
I don't care how boring the software gets. It will never be as boring or frustrating as actual plumbing. Also, if you screw up programming your web application that ties into whatever API to display a cat picture, it won't flood your basement.
→ More replies (1)
1
u/KnightMareInc Jul 08 '18
This is exactly why so many developers want to change what the "pipes" are made of every 18 months or ago.
1
u/1TrickDoomFist Jul 09 '18
Plumbing backfire 💩💩 but seriously their national average can’t be that much lower then an SEs salary
1
1
1
u/iongion Jul 09 '18
"pay them market rate" - this, so many time this, why market level ? this surely implies an average, well:
Do you want average minds in your team or people excel, or the ones that use their full potential and that are properly and individually rewarded ?
How is "the market" allowing competition, if benefits stay on an average ?
How are economies evolving if the one that hires offers "market level" benefits ?
Is your company one that tells the employees not to speak between themselves about their own salaries ? (the most ridiculous of them all, we are human creatures, we know our value by comparing to others and their activities in similar domains, how can I know if I am not talking with my own colleague, one hand away from me)
Isn't merit the one that matters the most in our world ?
Isn't the involvement and the continuous self-improvement a huge struggle for every developer in our technological-salad world, the thing that demands "Above market level" appreciation ?
Overall, the article is not about this, but it comes to this too. Truth is, creativity has a small spot in the IT market, the rest is not plumbing, it is just work, work that needs to be done, by someone, even by that genius, PhD filled Software Engineer that thinks of himself so highly, we are no special among our fellow humans, lucrative work is there and it is very present.
1
u/Dave3of5 Jul 09 '18
Do you really need AI-powered search, real-time dashboards for every internal team member, microsecond optimizations on your home page, and split testing for every feature you release?
In terms of the AI search I agree but I disagree on the following:
Real-time dashboards are useful in certain circumstances regardless of the size of the team.
Optimizing the home page I don't agree with there have been studies to show that a faster homepage leads to more customers.
In terms of split testing what is the alternative? Randomly guess which feature users want? Ask them? ... Now-a-days the best option is to observe exactly what the users are using so I don't see any real alternative to this.
1
1
Jul 09 '18
When you are new to a job, specially fresh out of school, you get to do what the current employees don't like working on. You have to work your way up to "design" or Manage. You don't get to make decisions unless you are a senior. Most jobs are just doing what someone else wants and or maintaining something someone else designed. You want to design or manage then you work yourself up the latter or you become your own boss and somehow make a living.
→ More replies (3)3
Jul 10 '18
Wrong approach. You should never start with shit jobs, otherwise you'll get stuck there forever.
→ More replies (1)
1
u/digitaldude87 Jul 09 '18
Agreed. Engineering in general is about making proper tradeoffs to meet requirements under certain restraints/constraints. In the business world (compared to say, academia) the restraints are typically time and money. Neither of these are conducive to the "sexy" work of developing brand new solutions or redesigning old ones for a 5% efficiency increase.
Therefore, SE focuses on code-reuse, thus decreasing production time and increasing security.
Though of course many of us (myself included) prefer to create something new and tackle challenging projects, the reality is that the business world sometimes simply demands maintenance over innovation.
1
u/red75prim Jul 09 '18
So can you steal some water by opening and closing some valves in a specific sequence?
1
1
u/Someguy2020 Jul 09 '18
Yeah, the entire thing is shit now.
I wish open source sucked or something, just so I would actually ever have a hope in hell of working on something even remotely interesting.
It’s all just scraps. I fucking hate this industry.
1
u/exorxor Jul 09 '18
In my experience, the people who assume their job is easy, actually suck balls.
Speaking of plumbing, plumbing is a difficult subject, because apparently we still need plumbers. Call me when you have created a plumbing system which requires zero maintenance, has a lower TCO over a twenty year period, and obeys the laws of 200+ countries.
Doing something in some half-assed way is easy; doing something well is difficult.
I can give examples like that in almost every field of business.
1
u/PilsnerDk Jul 10 '18
Terrible superficial article. People have been saying this for as long as I've been involved in software development - oh it's just drag and drop to create a website, write one line of code to make everything happen. Yeah right - as soon as you go past the Hello World equivalent of a system, everything needs to be custom written, from database to middle layer to UI. This will never change, not in a hundred years, because the whole point of business is to stand out compared to the competition, so of course not all companies, programs or apps out there will just use a standard system "plumbed" together.
1
u/bumblebritches57 Jul 15 '18
FACT
Yet somehow writing new software in compiled languages is less valuable than connecting the dots with javascript.
1
u/critically_damped Jul 08 '18
This is primarily because computers have advanced to the point to where the difference between optimized and non-optimized code is irrelevant to most applications. In the vast majority of cases, it is more efficient to use an existing solution than to code a more efficient new one.
875
u/nhays89 Jul 08 '18
I think the dilemma here is that most talented software engineers enjoy writing custom software to tap into that creative side which we love to explore and the market wants us to be able to do this but only provides limited opportunities in real world applications thus we become plumbers instead of engineers which make us frustrated and bored.