
Software Engineering is different from Programming - ScotterC
https://medium.com/@samerbuna/software-engineering-is-different-from-programming-b108c135af26
======
unpwn
Wow, medium contents behind a login wall now? In the wise words of mean girls:

>stop trying to make medium happen! It's not going to happen!

~~~
dickbasedregex
Esp. not with this annoyance.

I guess Medium is one more domain to mentally filter out.

------
crimsonalucard
I don't think of it this way. While engineering is certainly required I think
of engineering as overhead and the more engineering you have to do is
indicative of a problem somewhere else.

Take javascript: Javascript is probably the technology with the most
engineering overhead in the world. Javascript is so bad that all practitioners
of front end engineering have a huge amount of engineering overhead to deal
with whether that's through automated testing or manual tests. This all comes
down to : Lack of type checking, browser fragmentation. Would you write
airplane controller software or airbag deployment software in javascript? No.

There would be significantly smaller engineering overhead if someone say wrote
a backend application in Go. Needless to say the original author is a
javascript/front end dude.

>If someone does not understand the problem, they should not be allowed to
program a solution for it.

You ever done agile? You'd never engineer a bridge using agile. Agile is
indicative of lack of understanding of a problem which is typical of 99% of
software engineering. We simply do not fully understand business requirements
until a product is deployed. So we deploy a project first and iterate and
deploy again. Iteration is continuous and indefinite because real
understanding of the business "problem" is never complete.

~~~
gramstrong
That's a poor analogy for agile. A better one would be knowing that you need
to build a bridge, pave a road, and demo a building.

You determine that for this sprint, you need to build that bridge, because
it's blocking off commuters and hurting commerce. You KNOW how to engineer a
bridge, and you've just decided to dedicate this next iteration to doing that.

Next sprint, let's say you still haven't finished the bridge...but the
building that needs to be demo'd has deteriorated to the point that it is an
immediate threat to public safety. So you decide to pause the bridge building
and focus on the demolition. But you KNOW how to engineer a demolition.

Understanding business requirements is different from engineering, anyhow. But
don't conflate re-prioritizing with not knowing business requirements. Agile
doesn't describe how you should do something, it just determines when you
should do it.

~~~
megaman22
The end result of this process is that nothing ever actually gets finished -
you just fight the fire of the week forever, and ever, and ever. Meanwhile
your half-finished bridge starts rusting away and collapses.

