Software Engineering is different from Programming
medium.com
medium.com
>stop trying to make medium happen! It's not going to happen!
I guess Medium is one more domain to mentally filter out.
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.
I went to a developer meetup on Monday and one of the talks was about embedded JavaScript.
Would you or I do it? No but someone probably would.
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.