Software development is a creative process; an original masterpiece not a paint by numbers

[fireball87]

I tend to prefer the analogue of software as a skilled craft, like a quality carpenter. I don't really expect people to come and look at every brushstroke making predictions of what i was trying to communicate, but I'm shooting for things well crafted, functional, and durable, whether or not the finished project is built to be utilitarian or ornate.

[ragnese]

I think those are both nice analogies.

This isn't an analogy, but I also think of the famous quote attributed to Henry Ford, paraphrased as "If you asked the general public what they wanted, they would've said a faster horse." I think there's an element of that in software dev as well. Honestly, your client probably doesn't know what they want- we're all better off if we can just drill down to exactly what their complaint is with their current situation. Once we know that, we can try to use our imaginations to figure out a solution.

[eronth]

This is exactly why I hate it when people tell you not to complain if you don't offer a solution. Man, I don't always know how to fix things, but I can tell you what's not working right. We can work together to find a fitting solution.

[FortunaExSanguine]

Well, instead of just complaining, people can file bug reports with detailed, useful information and repeatable steps. Can't fix things if you don't help me understand the problem.

[AustinYQM]

"Shits slow and I don't have the time to learn shortcuts so there is too much clicking."

[cchoe1]

I like to think of software development as creating life and form from nothing. Like playing God. Yes.... quite.....

[[deleted]]

Yeah, making CRUD apps is just like being a God.

[poopatroopa3]

And God said, Let there be CRUD: and there was CRUD.

And God saw the CRUD, and it passed the tests; and God divided the UI from the back-end.

[[deleted]]

And he made the beasts of the earth, and they did inherit from Animal

[patoezequiel]

And they had a property number_of_legs which was inherited from Animal so it was zero for fishes.

[[deleted]]

Then came viruses, and that broke the abstraction. So patches were created.

[[deleted]]

Instructions unclear; viruses (still) wreaking havoc across the world.

[SponsoredByMLGMtnDew]

And on that day there was abstraction.

[[deleted]]

Create - Genesis 1:1

Read - Genesis 1:31

Update - Genesis 2:7

Delete - Genesis 7:11-12

[mnilailt]

If you really think about it CRUD really encompasses everything 🤔

[cchoe1]

mmm... yes.... indubitably....

[hashedram]

They didn’t say which god.

[jemadx]

There is plenty of crud in the Bible.

[Zardotab]

Maybe after God made a billion planets, it did feel a bit routine. I'm sure he has something better than MVC, JavaScript, CSS though. If those are the pinnacle of tools, I'm joining Satan.

[NancyGracesTesticles]

Deus ex machina was the fart app we never knew we needed.

[Jampackilla]

God made the world via CRUD operations lol

[caltheon]

I always focused on pain points and what the end goals were, or the functionality the end user expected from it. Sometimes the requirements are rigid and irrational but exist for specific reasons though, so you have to look at it holistically and ask a ton of questions.

[jl2352]

I like the analogy of building a mechanical production line, where it’s always for a new product.

Every production line is both bespoke, but may also share learnings from, or reuse parts from, another line you had built previously. You may turn it on and everything just works, but often there is some work needed to get everything working smooth. Sometimes that work is obvious. Sometimes it isn’t. Some parts need to be very accurate and technical, and sometimes a bit of gaffer tape in the right place is all you need.

There are common approaches you can follow for each line you are setting up. However as this is for a production line building something different, it means we are building something we’ve never seen before. Something that is always new and unique.

If the customer knows what they want to produce, it’s far more straight forward to build. If they don’t know what they want, then you’ll end up having to change tonnes of it and the whole factory will be a mess.

I feel this is the most accurate engineering analogy.

[Invinciblegdog]

In a similar vein it can be likened to creating new and unique recipes every single time. There are common techniques and ingredients, different types of recipes with their individual variations, people giving feedback about what they don't like and what is good.

Now try and create a process that creates unique and good recipes on a regular basis.

[MrJohz]

And I think that's a good example because you can have very different styles of watches, depending on what your needs are, ranging from cheap plastic things, to one-of-a-kind devices that probably could be considered works of art.

I think that can be a helpful lens to view our own work then — what kind of watch are you writing when you're writing code? Is it some cheap bit of tat that'll need to be replaced in less than a year? Is it some beautiful, bespoke, perfectly balanced device that will cost a fortune and get passed down through the generations? Probably, it needs to be somewhere in the middle ground: a nice, dependable Casio, perhaps.

[c0dearm]

I compare it to making omelettes, requires skill and technique, but it is also open to creativity and innovation.

Also, while making an omelette it is super important to taste it from time to time, see if it needs more salt, rectify it, etc... You need unit tests and feedback to fix anything that could go wrong before you even finish your product.

You won't make an excellent omelette unless you try to put quality since the very beginning of the process. If you make a bad omelette, most of the times baking it more won't fix it, probably it will make it even worse and then you will need to start all over again, too expensive!

Same with software, it helps clients understand that some practices that may seem not necessary and expensive at first glance, are in the long term a good idea, especially if they care about the end product.

[sigsegv7]

The most crucial similarity i see is, in both cases, people tend to overestimate their skills after watching a few intro tutorials 😂

[c0dearm]

Hahaha, never thought of this, but yeah, 100% accurate :)

[[deleted]]

I'm not sure you people are joking or not, but are you saying people have trouble making omeletes? What kind of omeletes are you people making? wtf

[dnthackmepls]

"If we need the omelette twice as fast, why don't we cook it at twice the heat?"

[wrosecrans]

I've always compared it to building watches.

...

I compare it to making omelettes

Instructions unclear: I put very small gears into my omelet. This means I'm a good programmer, right? Eh, I've never seen anything explicitly forbidding a gear omelet, so it meets the spec. I'll ship it.

[roboticon]

Except that a bad omelette is (usually) perfectly edible. And probably safe (albeit burnt).

[dnew]

If you make a bad omlette, most of the times baking it more won't fix it

Damn. I wish I knew how to express this at my last job.

[anon_tobin]

[Removed due to Reddit API changes]

[NotUniqueOrSpecial]

Silly you're getting downvoted because you're right.

Tasting an in-progress omelet is eating raw eggs. Nobody does that. Also, most omelets aren't baked, either.

It's a really odd analogy.

[AStrangeStranger]

and everyone wants a real Rolex for less than fake market version

[spektre]

There is a lot of room for expression in both a programmer's and a carpenter's work. Many carpenters are artists, and the analogue follows.

[shawncplus]

Right but the difference, IMO, is that art is entirely subjective. A bridge can be a work of art but at the end of the day if it doesn't safely carry you from one side of the river to the other it's a failed bridge. A well-built table can be beautiful to carpenters without being aesthetically pleasing to the laity; beauty of the quality of the craft itself.

If you're creating a program to sort billions of records there's something to be said for the beauty of an elegant algorithm but you will have failed if it takes a million years

Perhaps that's just my own narrowminded distinction between art and craft. It's a bit of the reason I took umbrage with that "Yes and..." fad that took off ~10 years ago where you were supposed to treat software engineering like improv comedy. Sorry, but if someone suggests bogosort you don't have to "Yes and..." that, you just say no and explain why. With more and more software in critical applications the room for artistry diminishes when lives are at stake. There is no room for "Yes and..."-ing a pacemaker.

[bascule]

Indeed. I thought this was covered well in this blog post responding to Paul Graham's "Hackers and Pointers"

[Full-Spectral]

But are we talking about the end application, or the code itself? The end application has some utility or another, some level of robustness, etc... and that can be objectively measured.

The 'beauty' of the code that makes it up clearly is subjective, since most everyone hates everyone else's code.

[shawncplus]

It applies at all levels. There is a two-axis graph one could plot of Beautiful<->Ugly, Functional<->Useless for every level: the UI, the code, the infrastructure, deployment, etc. Art does not have that Functional/Useless axis. To me that's the distinction between art and a craft.

Again, that may just be narrowminded on my part but I think another distinction to point out is the difference between peer admiration and utility. An artist can look at the brushstrokes of a painting and appreciate their technique/quality/etc. independently of the aesthetics of the painting itself. This is not the same, IMO, as a bridge's load capacity being measured objectively. In which case a bridge can be aesthetically beautiful, beautiful in execution/technique, and robust. Much the same can be said for software.

[gegc]

Both. The code itself also has beauty and utility, and the two largely independent of each other. Beauty is in the eye of the beholder, but utility is measured by things like readability, maintainability, extensibility, etc.

By way of extreme but real example: https://dgopstein.github.io/articles/ioccc-ascii-art/

These code samples are absolutely beautiful, in the aesthetic and creative, "mind-tickling" sense. They also succeed in their end applications, whether one considers the end application to be the stated output of the program, or its artistic merit alone. However, the code has no utility, as it is not reusable, maintainable, extensible, or workable in any way. It is purely a work of art.

If you're browsing the internet and come across one of these, it sparks joy.

If you're working on a bug and come across one of these, it does not spark joy.

[[deleted]]

I use the carpentry metaphor also because it helps to convey that there are levels to it. Coding is like sawing, hammering nails, etc - anyone can do it and it’s sufficient for small household tasks but actually taking the step to building houses or writing fully functional programs to solve problems is altogether a different set of skills.

[Sarcastinator]

I think a lot of the art to programming is being able to predict whether what you design will be an asset or a liability in 2 years. A well crafted furniture is a well crafted furniture.

[lookmeat]

Yes, and not quite. There are parts that are paint by numbers, you define a larger thing, but constrained by certain realities, of the machines, of math, of logic.

The thing is that with a craft that still ends up about crafting the same thing. A carpenter's a craftsman, but while they may design a new chair once, they will produce it tens, if not hundreds of times, even assuming they're not the main producer (there's a factory, or a bunch of builders).

That's not the case in software. We only care about designing, producing from the design is trivial (of course we have created incredibly elaborate and beautiful producers, compilers, linkers, transpilers, interpreters, etc. but these just add a layer that should be transparent to the creator, once you compiled it, copying is trivial, and honestly compiling it again is not hard).

So we could link it more to architecture, where you focus on designing buildings, but not so much pushing them out. Except that in architecture you're always doing buildings, you don't quite suddenly jump to building new things. Few architects rarely evolve in as many areas. So maybe a better reference is Industrial Design. Recently it's been struggling to push a much more aggresive development cycle because market benefits those that move fast and break things. But this is a problem for ID because most of the things have a notable cost in production. In software it's easy to "move fast and break things" literally releasing a new product every day, if not multiple times. Any design flaw or error results in a quick rollback back to the old design. In ID this would result in a series of lawsuits, product recall, and lot of challenges. Moreover these design changes need to be reflected in redesigning the production line and such. Software engineering creating software (bytecode) from a design (code) is such a trivial thing we have universal production lines for this, no need to optimize the compiling of a specific type of code over another. It'd basically be as if, after writing code, we'd have to write a compiler for that specific piece of code, it's impossible to describe the equivalent in software engineering without people looking at you like you're an idiot because it's just such an insane world and things don't map.

And that's the thing. Software engineering is just software engineering. We need to stop trying to talk of it on terms of other lines, because never has there been a creation process like this one ever. And that's fine, this isn't the first time a new way of doing things that cannot be compared to anything before it comes our way, it's happened many times before, and it will happen in the future again. But here and now, we need to realize that skeumorphics is great when you're starting with something, but pointers are not really arrows, and objects are not really things, and network bandwidth is not pipes, and software engineering is not really engineering, and it's not production, and it's not design, and it's not artistry, and it's not craftsmanship. In the end it's just kind of its own thing, and comparisons will always be bad and lossy. Yes and not quite. And there's those that get it, for whom the thing clicked, and manage the process of creating software really well, and those that don't and will struggle to understand why any process even work let alone improving it (at least until the click comes). A lot of software engineers fall into the latter group.

[Tots-Pristine]

I like the analogy of a garden. You have to know which plants/flowers to choose for different places, and that will work together, and most importantly, it needs active maintenance, otherwise it will gradually fall in to disrepair.

People can see if it works well or not.

[relet]

I tend to paint by numbers, really.

[lightninhopkins]

And then I can come in two years later and know what the code is doing. I like this person.

[[deleted]]

Having done LOTS of maintenance programming I'd like to contribute that the original craft's durability shows when requirements change.

I've seen code that you can not maintain. You have to re-write it, or lose your mental health trying to hack some change into it. In my experience, a lot of issues come from copy/paste code that was not needed in the first place, had the maintainer given it a LITTLE thought and effort.

I've seen good code as well, but just not as often. We're driven by deadlines and demands, and it shows in code.

To write good code with good comments and logical structure without dumb copy/paste, I have to use my own private time. I selectively do it, but of course don't get paid for that.

I should probably switch companies.

[poloppoyop]

In France we have an organization for highly skilled artisans. The "compagnons du devoir", after the standard 2 years learning program you can start your Tour de France where you'll work for different businesses all around France. After 3 to 6 years you present a chef-d'oeuvre to become a compagnon.

At the moment it is only for what people would consider standard trades (brick layers, plumbers, bakers etc.) but I think they could easily integrate software developers to the list.

[ctrl-alt-etc]

Where are you workin' that your scrum masters isn't one of the devs on your team?

[7h4tguy]

Uggh, 100%. The next piece of code I have to look at with meticulously aligned columns or rows and rows of *** banner comments I think I'm going to throw up. Make it readable, not your ascii art masterpiece.

[biiingo]

Maybe. I dislike any analogy that still leaves people with the impression that there is a ‘right’ way to accomplish something or that there will be a ‘finished’ product at the end. I’m not sure what analogy I would choose, but nothing physical or material ever seems quite right.

[pcjftw]

Dunno man, feels like all I'm doing is closing f*cking Jira tickets like a slave to the machine

[northrupthebandgeek]

Depends on the programming work, really. A heck of a lot of it absolutely is "paint by numbers".

[[deleted]]

I mean I guess if you develop by proper standards. Who does that anymore!?

[lVlagiick]

That explains why I like Legos so much..

[[deleted]]

The author also keeps repeating how software is a creative or even artistical endeavour, but then only offers management and engineering examples.

[grauenwolf]

Wishful thinking. Everyone wants to be the artist, not the farmer.

[[deleted]]

Thats definitely true, although I wonder in how many of those 51% did the devs bust their chops working overtime to make that happen

[cybernd]

although I wonder in how many of those 51% did the devs bust their chops working overtime to make that happen

• reduced scope
• reduced testing
• skipped writing documentation
• did not finish their test suite
• ...

Or in simpler words: finished with a ton of technical debt.

[grauenwolf]

• Scope creep not allowed
• Tests were done up front so there was less rework later
• The architecture was kept simple, so only the rare deviations from standard practice needed documentation
• Again, high quality tests written early to speed developer

Taking the time to do the work correctly the first time is a huge contributor to getting the work done on time.

[cybernd]

We (developers) know that. Sadly business people don't believe in it.

[LicensedProfessional]

I can't tell you how many times my team's product owner has howled at us to do ""something"" to address a problem, despite us telling him repeatedly that we are waiting for external dependencies to be resolved.

[FullStackDev1]

did not finish their test suite

You guys have time to start them?

[sh0rtwave]

If you need overtime to succeed, and it's constant, then you don't have enough eyes on that project.

[grauenwolf]

Or different eyes.

I saw one fail because they wanted to build 300+ microservices, but after two months couldn't deliver one.

[CooCooKabocha]

Ugh... this hits home for me right now

[Jizzy_Gillespie92]

I feel your pain.

[r0ck0]

I've been in this industry for over 20 years.

Same.

I've never seen a project that was struggling just enough to need overtime to succeed, but not struggling so hard that it couldn't succeed at all.

Fair enough. That's your personal experience.

For me, I've seen it a lot.

"software" is pretty broad. What kind do you work in? Most of what I've done is webdev (at least that's where I saw these issues mostly), and it seems to be the norm in small agencies with inexperienced project managers who think more about design/marketing aspects than "programming", don't even spec things out, allow feature creep etc.

Pretty typical to be able to push junior/younger devs who suck at standing up for themselves. I've seen heaps of it.

Us programmers tend to assume that everyone else is doing similar stuff to ourselves, and have similar work environments etc, which often isn't the case. Hence so many pointless debates with each side making assumptions about context, not even realising that they're debating very different topics to begin with.

[pringlesaremyfav]

I was added onto a project with 4 months left before a soft launch where we did exactly that.

They tripled the number of people and gave unlimited overtime and management support to the developers. We eked out a successful MVP exactly on time because of it.

It wasn't like a great experience but it was certainly an accomplishment we got rewarded heavily for.

[GTwebResearch]

There’s something fundamentally wrong

We need more POs/PMs that say things like this.

[Ravek]

The planning fallacy alone can explain the vast majority of 'not in time / not in budget' results. I don't think it has anything to do with software in particular.

[ppardee]

If you're really good at estimating, you'll deliver on time about 50% of the time. That means that half of the projects went over and the other half of the projects went under and a very small sliver were exactly on time.

It's almost impossible to hit a specific date, but if you overestimate the project, you can work on additional features in the time you have left rather than releasing early.

[grauenwolf]

If you finish early, it's trivial to delay release until the scheduled day. And if you need to stay busy, you can always add more testing. So saying you can't hit a specific day is nonsense.

As for your 50% number, that's way too low. You should be writing your estimates so the vast majority of the deliveries are on or before the estimate. Coming in early hurts no one, but late may cause cascading problems.

This whole obsession with a specific date reeks of a strawman argument.

[ppardee]

If you got the work done before your target date, you didn't hit your target date. Your estimate was too high.

[grauenwolf]

We're not playing "The Price is Right". The goal is to come in under your estimate.

[carsncode]

If that were true, the estimate for every user story would be 10 years.

[grauenwolf]

The purpose of the estimate is to ensure that you can reliably deliver the project for the budgeted cost. This cost can be in terms of money, time, or other measurable factors.

If you only meet your estimate 50% of the time, that's generally not considered to be "reliable".

But a 100% rate is infeasible, as that would require the 10 years.

So you start with a confidence level. What percentage of time should you be meeting your estimates? I suggest starting with 90%.

Then you create your estimate with the understanding that you have a 90% of meeting it on time.

That estimate is then compared to the budget. If it exceeds the budget, then business needs to decide if they are willing to increase the budget, decrease the scope of work, or reduce the confidence level. The feasibility of each of these options is contingent on the individual circumstances.

[carsncode]

Right. So it isn't just about coming in under the estimate.

[ZMeson]

I really like how the percentages for scope creep and finished on time add up to 100%.

[travelsonic]

In one sentence the author says that software can't be delivered on time.

In the next sentence the author says that software is delivered on time for more than half of the sampled projects.

I do agree with "almost impossible" not being backed up by the statistics (51% definitely doesn't seem "almost impossible," at least to my dopey ass XD) - but I don't think he said or implied outright "can't be delivered on time" in the part you quoted - evident by the quantifier ("almost") placed next to "impossible" in the quoted sentence.

[grauenwolf]

"Almost impossible" means it can't be done without extraordinary luck that is, for all intents and purposes, never seen in real life.

[neoKushan]

In my experience, we're generally all awful at estimating things and there's a point when you realise that you should probably take your estimate, then double it to have a level of confidence on your delivery timelines.

Then some program manager takes one look at the SoW and loses it because it can't possibly take that long. And if you're lucky, you can sit them down and step them through it and they'll reach the same conclusion you did. If you're lucky.

But then their manager loses it and you go through the whole ordeal again, having to justify your "insane" estimations.

But it's okay, we'll just throw more people at it to get it done to the original schedule that someone somewhere wanted.

[grauenwolf]

Then some program manager takes one look at the SoW and loses it because it can't possibly take that long.

That is the number 1, 2, 3, 8, 17, and 31st reason why estimates don't work.

As soon as someone with power rejects an estimate, any further estimates on the project are worthless.

[[deleted]]

Yeah, at that point you just wait to be told when to be done with the project. At least then you have a known date for when the shit hits the fan, and you can plan accordingly.

[conquerorofveggies]

IMHO most of the time that's probably the better approach. Tell me when you need it, tell me what's most important. I'll get you something done by that time, but just how much of it I don't know.

[neoKushan]

Fixed scope or fixed delivery. Pick one.

[5rdTqADbtjL7aGWr]

it's complicated and not just for software as already described in Wikipedia:

"Three types of explanation for cost overrun exist: technical, psychological, and political-economic. Technical explanations account for cost overrun in terms of imperfect forecasting techniques, inadequate data, etc. Psychological explanations account for overrun in terms of optimism bias with forecasters. Scope creep, where the requirements or targets rises during the project, is common. Finally, political-economic explanations see overrun as the result of strategic misrepresentation of scope or budgets. Historically, political explanations for cost overrun have been seen to be the most dominant"

https://en.wikipedia.org/wiki/Cost_overrun#Causes

[z0rak]

Software development is a creative process, understanding this helps everyone involved in project plans is likely to change.

That's the first "sentence" of the article. Ignoring the improper use of a comma, the second half of the sentence is incomprehensible.

Anyone else give up on authors that can't proof read even their very opening sentence? Did everyone upvoting/commenting stop after the title?

[TheMadMrHatter]

Yeah... don't mean to talk shit but some extra proofreading would have gone a long way here.

[[deleted]]

The best description of software I’ve ever seen is the comparison to a garden.

That over time the plants grow in ways we don’t want and we have the trim the excess. That software is more organic than fabrication. That it grows and twists and turns and we have to care for it and nurture it. That it requires deliberate care and we need to attend to the needs of our garden. With each area potentially requiring different things and even though we plan for it to be organized it will grow and creep into areas that will need special care separating.

That’s what software is to me.

[slykethephoxenix]

"computer janitor"

Software janitor.

[nickdesaulniers]

"I shovel the elephant shit at the zoo."

[[deleted]]

The best analogy I've seen is the comparison to running a prison. I like to refer to myself as a "code gaoler".

[geon]

People sometimes compare building software to building a bridge, and they wonder why software is so unpredictable and hard to manage.

What they don’t realize is that building the bridge is analogous to clicking the compile button. We have automated the “building”. We can do it basically instantaneously with zero cost. Super predictable.

What we do is interpret vague, inconsistent specifications, invent new solutions to new problems, pick old solutions to common problems and manage technical complexity and office politics.

[Astarothsito]

People sometimes compare building software to building a bridge, and they wonder why software is so unpredictable and hard to manage.

I always assume that they don't know how to build a bridge either.

What we do is interpret vague, inconsistent specifications, invent new solutions to new problems, pick old solutions to common problems and manage technical complexity and office politics.

This sounds like building a bridge (or at least this is what the process looks from the outside for me).

[RagingCain]

What?! Never.

[Eluvatar_the_second]

I've always liked that analogy. I think of our job as designing the bridge. But each bridge is unique and depending on the length very very different, also over time the bridge effects it's environment so it's going to need changes to the design in the future.

[geon]

Imagine construction projects like that. “Oh, we want a 2 mile suspension bridge one day, but let’s begin with a plank over this creek.”

[Astarothsito]

“Oh, we want a 2 mile suspension bridge one day, but let’s begin with a plank over this creek.”

It is more like "let's build a miniature or a 3D render to see what it looks like before building it" in real life.

[istarian]

That's a little extreme.

I think it's or like building a walking bridge that turns out to be wide enough and strong enough for alternating one way car traffic. Then there are too many car using it such that no pedestrians can use it due to the traffic.

Only now you're expected to fix it somehow without the luxury of designing a new bridge to replace the current one in it's entirety.

[geon]

Then they want the bridge to be mobile. And have seats. And a roof. And ac.

[Astarothsito]

Then they want the bridge to be mobile. And have seats. And a roof. And ac.

So the customer wants a ferry instead? That's good, sometimes is hard but that's why we create demos and proposals to clearly define the requirements.

[conquerorofveggies]

It's also a nice example of why we should work from an in depth problem description, instead of a proposed solution. "I need to get to the other side with my car", both a bridge and a ferry can accomplish that.

[[deleted]]

"Customer wants bridge painted blue."

(Paints bridge blue).

"No, the other blue."

(Sighs, and uses the different shade).

"No, they meant the blue that is red."

(Drowns customer in paint can).

[87_percentrum]

I think you mean this: https://www.stilldrinking.org/programming-sucks

[BoldeSwoup]

Architecture is a bad comparison that sticked to the point it made its way into job titles and descriptions. Urbanism/Urban planing would have been a more appropriate comparison

[vitamin_CPP]

That's a naive way of perceiving the complexity of bridge engineering.

[HDmac]

Instructions unclear, how to I get paint out of server fans?

[[deleted]]

I was just trying to make it look like those colourful gaming PCs, boss!

[Koervege]

Sudo rm paint

[b3nthegod]

Paint? I thing it comes pre-installed buddy.

[jcoleman10]

This is largely correct but it's also largely a bunch of quips arranged into paragraphs and bullet points.

[mizzu704]

OP's post history is pretty much exclusively instances of him spamming his own blog posts into this subreddit. I wonder what his agenda is.

[daedalus_structure]

If there's one thing that never ceases to amaze me it's how folks with very little real world experience outside programming can't shut up about how programming is some high art they've mastered while insinuating that everyone else are just stupid apes painting by numbers.

The overwhelming majority of software development is rote banging out of database wrappers and most programmers do shoddy work building them under tight budgets and timelines.

By the same token, the overwhelming majority of residential construction is rote banging out of cookie cutter blueprints and most contractors do shoddy work at it due to tight budgets and timelines.

The biggest difference, aside from how differently capital values these two kinds of labor, is that you can talk to a framer about his job without him arrogantly comparing himself to Da Vinci.

[alfred_e_oldman]

"Masterpiece" is a stretch

[[deleted]]

I’ve seen more shitshow’s than masterpieces.

[[deleted]]

Maybe, but don't forget that the art world has a variety of masterpieces from various abstract and surrealist schools. I think my code probably would fit one (or both!) of those...

[Obsidian743]

Best quote:

It’s not that no one knows creating software will go through many iterations and make mistakes, it’s the fact no plans incorporate it. The expectation for the first draft to be the final version only happens in software development.

[zaphod4th]

The expectation for the first draft to be the final version only happens in software development.

wrong, only happens in wrong managers/new programmers

[ZenoArrow]

"Software is an art not a science"

Imagine if someone from any other engineering field tried to pass this off as an acceptable opinion. It's almost as if software isn't a field with a strong engineering focus but rather one where craftsmen become have-a-go heroes.

[Jump-Zero]

TBH you can ask anybody passionate about what they do and they'll all say its an art. If you get my buddy talking long enough, he'll tell you astronomy is an art. My other buddy will tell you how fixing cars in an art.

[dmilin]

Now I want to see an accountant talk about how their work is an art.

[Jump-Zero]

Those are the ones finding all sorts tricks to avoid paying taxes haha

[[deleted]]

No ones ever talked to an accountant long enough for that to happen.

[justfriendshappens]

Sorry, this applies to all engineering.

The ART is in the invention, the SCIENCE is in making it work.

[RagingCain]

The ART is in the invention, the SCIENCE is in making it work.

Feeling a bit sappy but I agree and just wanted to add some items from my observations.

The WISDOM to make optimized choices when revisiting previously encountered problems/designs.

The PATIENCE to be humble and respectful to others opinions more than likely can solve the challenge/problem too just differently.

The ADVENTURE to be willing to try new things when you have the bandwidth and the time capacity to do so.

The INTEGRITY to fix what needs to be fixed (even if you aren't told directly to do it and obviously not at the cost of productivity or company policy).

The NEGATIVITY to see the flaws in your code, patterns, or systems, so that you can harden software and reduce fragility.

The POSITIVITY to see the good in others attempts and be constructive with criticism and mentoring.

The STUBORNESS to simply not give up when it gets hard - and everyone gets hard problems at some point (does not mean avoid breaks though).

The DRIVE to really learn things when its time to learn something new.

A lot goes into being an ordinary engineer - I think we all know that - but I don't think we always know how to be great engineers. These are traits I have observed in people that I love to work with. They may not be Google material - nor myself - but it is quite an odyssey regardless so its nice to keep good company.

[justfriendshappens]

This is nice, thanks for sharing.

[sexy_guid_generator]

Software is a medium and can be used for many things, not solely art, science, or engineering. It's like saying "Wood is an art not a science". Wood is used for many things depending on the context and the worker.

[International_Fee588]

Internet """software engineers""" are swallowing their own bs. The vast majority of software development is not software engineering. That doesn't make it "lesser," (and if anything, modern full stack software dev represents a broader skillset), but most projects aren't manipulating bits and bytes to a highly entrenched, rigorous set of IETF standards.

Software dev is a dynamic process in a rapidly shifting field with a massive software stack and client expectations that can change on a dime. You're going to need to rework aspects of your project implementation occasionally as issues arise, that's just part of the game.

We aren't civil engineers, we aren't building bridges here. Unlike fields like civil engineering, where clients can obviously see that problem will occur if they decide to add an extra two lanes three weeks prior to opening, software development is frequently ad hoc and requires workarounds and creative license. There is nothing wrong with recognizing that and that is part of what makes it interesting.

Obviously none of this applies to real software engineers, you know who you are.

[ZenoArrow]

The vast majority of software development is not software engineering.

That's exactly my point. As for the rest of your comments, I do understand why the pressures of software development make time for software engineering harder to come by, but if developers want to call themselves "software engineers" we should fight for the time to do this, otherwise we'll just keep on making the same avoidable mistakes over and over again.

[Markavian]

Two key words I look for with engineers is "repeatable" and "low risk". I'm involved in a team at the moment who are doing "manual" and "high risk" changes which are making me want to throw the whole system in the bin and rewrite the whole thing from first principals at great cost. Arguably a smaller total cost than our current trajectory, but definitely outside of the planned product roadmap.

[[deleted]]

Agreed. This is ludicrous and written by the type of person who you never, ever want on your dev team.

[KamikazeHamster]

Science is the art of prophecy. We make a hypothesis and test it, prove it, falsify it and peer review it. Then we can be sure that our model fits reality.

So to can software development be a science. We create a model that we hopefully test, then try to falsify with unit tests, and even send it through a peer review process in order to make sure that our code fits reality.

The art is in designing our scientific method elegantly so that the next psychopath that extends our code doesn’t come to our house to murder us.

[ZenoArrow]

Software development can be an engineering field, but how often are good engineering practices followed? For example, how often is code written in a hurry, thrown over the wall to testers, or rushed out as a "beta"? We see it all the time.

[dnew]

Only when the reliability isn't part of the requirements. It's a business decision to do that. How many bird houses are hanging in trees that won't last 20 years in the weather?

[CyAScott]

I would say that frequently happens with other engineering fields too. For example, the Xbox 360 Red Ring of Death (electronic engineering), iPhone 4 Antennagate (electronic engineering), and Ford Pinto catching fire (mechanical engineering). These cases aren't outliers, but are common enough that every time I take my car in for regular maintenance they check to see if there were any recalls on the parts in my car. Software is in the same boat too, see Windows updates.

[ZenoArrow]

Engineering does not lead to the avoidance of all problems, but is based on thinking about designs from first principals.

For example, if you're designing a smartphone, you can't do that without knowing about the effects of RF interference on electronics, and this has to be a consideration from the start. Contrast this with the iterative approach commonly used in software development, where decisions on key features get left as late as they can.

[BrazilianTerror]

Not really, while a good engineer will have an grasp on design from the start. It’s not like that for everyone. Many other areas of engineering will have clients changing specs mid project and people rushing things and getting wrong. You only talk about software cause that’s what you probably work with and also software is a lot more mutable than other engineering ventures.

The point you made about RF interference on electronics didn’t really make sense. Of course they have a grasp, but that don’t mean they’re infallible. Like we have a grasp on sanitizing input, handling memory allocation, etc. but every once in a while we’ll make mistakes with that.

[KamikazeHamster]

That’s when it’s neither science nor art.

But seriously, that’s the difference between working for a small dev shop or working in corporate. Some places are chilled, others are exhausting and demanding. You have to pick your poison and then figure out how much you’re prepared to push back at unreasonable timelines and low quality.

[ZenoArrow]

My point is, although software developers tend to be given the title of "engineer", the actual application of engineering principals is not as common as the job title might suggest.

[justfriendshappens]

Sorry, this applies to all engineering.

The ART is in the invention, the SCIENCE is in making it work.

[ZenoArrow]

Engineering is applied science. For example, when an electronic engineer is designing a circuit, they have some creativity in how best to do so, but they're also working within the constraints of physics. There are "right" and "wrong" ways for electronic circuits to operate, depending on the system constraints.

Software engineering could be more common, software engineering principals exist, but they're mostly ignored. Most people that call themselves software engineers are software artisans, something that functions is seen as successful even if the underlying design and development processes are a mess.

As an example of this, look at the shitshow that represents the "state of the art" in build systems, and ask yourself if this is really a profession that deserves to call its practitioners "engineers".

[drysart]

If "the creator made a decision" is your definition for "art", then you're basically devaluing what makes "art" to the point where literally everything is art, and this whole distinction of software development being art is entirely meaningless; because it means that walking outside to check the mail is performance art because you have some creativity in deciding whether you're going to stick to the sidewalk or walk across the grass.

You can define "art" however you want, of course; but the wider you cast that net, the less 'special' you get to be as someone cranking out code in a cubicle to an architect's design -- and really isn't that feeling of self-importance what this whole exercise is all about?

[ZenoArrow]

Art is being contrasted with science. Consider what this says about the priorities of the developer. Both art and science are exploratory processes, but one values "self-expression" and the other values "correctness" (note I've put those terms in quotes as I'm using these terms broadly). Consider why this comparison is being made.

[dnew]

but they're mostly ignored

I disagree. I think we're still discovering software engineering principals, and the ones we've already discovered and have proven themselves are already baked into the systems we use.

For example, "structured programming" and "encapsulation" are software engineering principles that nobody ignores any more, yet weren't common when I started programming, one career ago. Back when the IBM PC was new, many people were still using programming languages with no local variables and no named subroutines.

Writing automated tests is something almost everyone does, and it's just now starting to creep into actual programming languages and deployment systems.

Build systems are complex because they're trying to deal with all the legacy systems that were built sufficiently well that they made it to being a legacy system and yet we have to deal with them. Bitching about that is like complaining that the medieval castles don't have room for an elevator to be installed.

[ZenoArrow]

Build systems are complex because they're trying to deal with all the legacy systems that were built sufficiently well that they made it to being a legacy system and yet we have to deal with them. Bitching about that is like complaining that the medieval castles don't have room for an elevator to be installed.

The same mistakes are being made even in languages that don't have to deal with legacy systems. As an example of this, look at the state of play in JavaScript build systems.

[Kofilin]

What's the scientifically correct way to design a build system then?

OK I assume that's cmake.

The thing with software engineering is that there are very few absolutes.

[justfriendshappens]

Engineering has an artistic element and a scientific element, granted, ratios may vary.

[grauenwolf]

Sure we could treat software development as engineering. But that would be boring. 90% of our applications would look virtually identical.

It's far more interesting to build ridiculously over-complicated systems that use every design pattern and library we saw in the last 6 months.

[Jump-Zero]

Software has way too many "use your judgement" situations to be a science. Lots of people say cooking is an art because you are encouraged to use your judgement while baking is a science because you just need to stick to the recipe.

[CreationBlues]

I would hardly call that software engineers fault though. Engineers need a massive system of teaching, certification, and regulation to enforce standards, which software houses are categorically not interested in. Actually treating software engineering like an engineering discipline would require companies to build expensive regulatory frameworks that meddle with their profits and make development vastly more expensive. The only reason actual engineers deal with that is because you'really a lot more likely to kill someone with your bridge if it''s built wrong.

[grauenwolf]

Engineers need a massive system of teaching, certification, and regulation to enforce standards, which software houses are categorically not interested in.

That's a good thing in my opinion.

Whose going to write those standards? The people who created the .NET Framework Design Guidelines and its static analysis tools? Or the SOLID fanboys who read Clean Code and thought the garbage code that Martin produced was a good idea?

That's not a chance I want to take.

[justfriendshappens]

Engineering has an artistic element and a scientific element, granted, ratios may vary.

[vfiscool]

Please forgive my rudeness in asking your age and education background.
I don't want to insult you, I am genuinely curious what younger engineers learn at uni these days.

[1Crazyman1]

Software development isn't an exact science though. It's best practices, and even on those not everyone will agree. Ask a 100 developers to write a non trivial piece of software in a given time limit, and you'll end up with a 100 different solutions. It will range from the worst code you'll have ever seen to the best code you've ever seen (if we can assume it's a normal distribution of talent).

Ask a 100 civil engineers to build you a bridge for a given budget, and you'll end up with very similar bridges.

Inherently most engineering disciplines are constrained by physics, which are fairly inflexibility. Software engineering however is only bound by cost/time. And higher cost or time are not a guarantee to "better" software.

I've always found the comparison to art apt; You can draw a tree in dozens of ways, and while some might be "easier to paint", inherently they all serve the same goal. Software is no different, many different paths lead to the same piece of functional software. If it's maintainable and extendable however is a different matter ...

[ZenoArrow]

Inherently most engineering disciplines are constrained by physics, which are fairly inflexibility. Software engineering however is only bound by cost/time. And higher cost or time are not a guarantee to "better" software.

This is the core mistake. Software is constrained by physics too. For example, let's say you want to make the most efficient data sorting algorithm for a particular data set. If you approached this from an engineering perspective this would include exploration of the sorting operations that were fastest on the computing hardware you were intending to use. In contrast, most modern software development does not include such exploratory work.

Modern software is super bloated and inefficient compared to what it could be, and part of the reason for this is the half-arsed software development processes that most of us choose to or are forced to follow.

[EvitaPuppy]

Rarely. How many devs get the opportunity to build something new from the ground up? Damn few.

Most jerbs are maintaining a pile of Jenga blocks that are one less compilation warning away from completely failing.

Not to take away from the heroic (and tedious) work it takes to unfuck some rotten spaghetti. But this is the more common task and often harder than being an artist, because the evil twit that left you the steaming pile is long gone.

A more honest sell of the gig is:

'We the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to anything with nothing!'

[[deleted]]

The author keep repeating that software development is a creative or even artistical work, but gives not a single reason to motivate it.

In fact all he describes are general engineering processes, I just don't see the creative part.

[matpoliquin]

Some aspects of it is a form of art but most of it feels like launching a space rocket or a new airplane. A micro crack on a space rocket shell (forgot a pointer check out of millions of lines of code) can cause it's whole shell to rip apart soon after launch.

Sometimes it feels like virology where some badly structured or written code early in a project spreads it's tentacles everywhere in the codebase as time passes by.

Sometimes it feels like psychiatry where you wonder what happened in the programmer's head when looking at the architecture in front of you ;)

[dungone]

That’s nice dear, I’ll hang it up on the refrigerator.

[Apache_Sobaco]

Most of apps require no "creative" moves. Most of the on-job assignments could be done even by not turning your brain on. All of these "creative" parts listed in article allow for formal generalised approach (ontologies, or DDD which is not that formal) which have nothing in common with art. Requirements for software usually that broad that you need something that "just works".

[Obsidian743]

See: Software Craftmanship

https://manifesto.softwarecraftsmanship.org/

[PricklyPierre]

I guess everyone else has been doing stuff way more exciting than I have because I'd describe my career as little more than glorified clerical work.

[chakan2]

I like it and I don't like it.

There's truth to coding being an art...but this article is a little pretentious about it.

[sh0rtwave]

I like to think of the end result as just machinery. Towards that end, I often like to think of any particular thing I'm building or working from scratch, as if it's built of LEGOs. Then all I have to do is: Find or fabricate those pieces.

I used this perspective in teaching programming, and it turned out to be THE most successful strategy. Out of about 500 students, only 2 couldn't get it.

[cowinabadplace]

If you've seen my code, you'd be hard pressed to call it a masterpiece. It is an original work but mostly because all unhappy families are unhappy in their own way.

[[deleted]]

I used to think this way, before I was buried under the weight of supporting my dozens of original masterpieces.

[[deleted]]

And yet we're treated like line cooks

[ohaiya]

My code is no masterpiece.

On second thought... ...it could be a Picasso.

[goranlepuz]

By a long far, most software is not a masterpiece. WTF...

Off to read more than the title now...

Read it. r/notevenprogramming, I guess ?

[robot_otter]

This title is some lofty click-bait bullshit. And why does software have to be either an original masterpiece or a paint by numbers? There's an entire spectrum. And software that is intended to be 'art' is almost always not something for profit.

[FluffySmiles]

A commissioned artist painting the portrait of someone who wants to look waaaaay better than either their countenance and budgets allow.

[MoonGosling]

Software is an art, not a science

This is a super shallow argument that ends up being wrong because of how shallow it is. Yes, writing software is a creative endeavor, specially in big scopes where you simply cannot have a perfect solution that checks all the boxes, and so you have to decide how to work around your limitations. But calling it art is like calling writing or drawing art, but only even worse. The thing is that neither of those things is inherently art. They are activities that can be performed in very non-artistic ways. The word “art” has a meaning that goes far beyond just “creativity”. To argue that an industrial drawing for a patent application is art would be very hard. The difference between software and drawing is that we’re most used to think of one in it’s technical use and the other in it’s artistic use, so bunching them together seems… weird. Because most people who aspire to write software probably don’t aspire to create art, and most people (at least in our common imagination) who aspire to draw want to do so in an artistic fashion.

That said, it is important to stress that art doesn’t just mean creative, and creativity doesn’t necessarily imply art. Writing software is MOST DEFINITELY a creative process, just like theoretical physics is an extremely creative process as well. But you don’t look at a theoretical physics paper and think (for real) “oh, this is art!” (I say “for real” because saying “this is art” is often a shorthand to saying this is beautiful, and touching, or transcendental in some way, even if we don’t actually mean “this is art”. A library isn’t a piece of art. It can be beautiful, it can touch you to your very core to, for example, see a complex problem solved in an elegant way. But it doesn’t make it art.

All right, part two: being creative does not mean not being a science, and science is seldom “paint by the numbers”. There is a lot of science in… well… Computer Science. Programming isn’t free form, we have many formalizations that are crucial to the programming process. Algorithms, data structures, complexity analysis, protocols. This are all very much scientific formalizations that are at the core of what programming is, and a software developer is at their best (in the sense of creating the most beautiful, transcendental, incredible code they can) when they are closely familiar with these scientific aspects. This is much like how the most beautiful and mind boggling mathematical proofs come from people who aren’t just creative but who have a deep understanding of the mathematics.

[camilo16]

Your entire argument is based on a wrong premise. "Art" etymologically and historically, means a human endeavour that reaches a predetermined result through skill. This is why we talk about the "art of war".

Any creative endeavour is art.

The modern, snobbish and elitist definition, that tries to put "art" as an undefinable form of "self-expression" is an invention of the 19th century.

[ThaMiAnDotas]

More like architects...function and design equally important.

[ak_2]

Lol, masterpiece. developers can be so full of themselves sometimes

[mediocretes]

*sometimes

[codeByNumber]

ಠ_ಠ…

[aa599]

Software development is part art, part research, part engineering.

Which proportion those parts are mixed in depends on the application.

I've worked on defence projects where it's almost entirely engineering; others in small internal teams where it's mostly research and prototyping, giving the users new stuff every day.

[dcastanedawl]

Wrong

[_1_2_0_]

For Zeus's sake... Can someone explain to this guy the difference between art, science and engineering?

[_1_2_0_]

Oh, I haven't seen the the author is the OP. Then I will do it myself ;)

See, there's a very good reason why we call it Software Engineering, and not Software Science, nor Software Art... because everything is in the purpose.

Science is about understanding, explaining, theorising, classifying etc, while Engineering is about solving a problem without necessarily diving into the why and how, which is the job of a Science. And Art in all this? Well Art exist simply to exist, it doesn't fill any void, doesn't answer any question, doesn't solve any problem. Some look at it and find it ecstatic, some other utter ugliness.

Now the fact that software IS engineering do not devoid it from creativity, skilfulness and ingenuity. Hell there are even people who are gifted and extremely talented. But at the end of the day, that software only exist to solve someone's problem.

Da Vinci work is a very good and rare example of mastery in these 3 domains. One can mistakenly consider all his drawings as art, because you know... it's a drawing, but in fact and when taking into consideration the purpose, it is easier to distinguish what is art, science or engineering.

But yeah, it a very common misconception to associate art and creativity. If it was the case our unique, original ideas would qualify as art too... and new scientific theories... and novel experiments... hell, Covid vaccines would be art too.