Live data from Hacker News

Anti Mediocracy Manifesto for Software Development

gabordemooij.com

51–60 of 110 posts

Re: Anti Mediocracy Manifesto for Software Development

#51
This is fantastic; the perfect example of tilting at windmills. So, I'll take up the role of Sancho.

Using tools to craft a work of art? I'm sure some projects deserve our collective accolades, but no one should consider them art. The only projects that should end up in a museum are those that are no longer in use.

Risk of bugs increases with each piece of code? I'm sure this is impossible. The risk is already 100%: there will be bugs. They only increase in volume.

Always be wary of fancy websites? I'm sure the rant preceding this nugget has a point (e.g. maybe "never compromise on code quality), but let's be honest: a fancy website is a work of art, See #1.

Withstood the tooth of time? I'm sure these mixed metaphors are meant to be poetic, but when you lead with a statement followed by an exception, then your whiskey spigot can engender an acreage of Hidalgo.

Re: Anti Mediocracy Manifesto for Software Development

#52
post #8

These lines sound like a recipe for scope/feature creep and never ending development process. >Never do requirement analysis. Never write technical requirements or functional ones. If you do, you have already failed. In that case, how do you know when the software is finished and your contract has been fulfilled? >Creative solutions are often holistic in nature, driven by first-hand experience, discussion, interactio…

you missed the point: The point is, if the requirements for a piece of code are so complex that you NEED to write a requirement analysis, that you NEED to do anything other than plan out your code, and write it, than your software is already too complicated. You need to narrow the scope. Lots of small systems is better than one large system.

Re: Anti Mediocracy Manifesto for Software Development

#53
This is either brilliant, or excellent satire. Which one it is depends on how you define the terms. There is good advice here, but if you take it literally, and don't pay attention to context, and use common sense, you'll end up with some really bad advice.

Re: Anti Mediocracy Manifesto for Software Development

#54
I'll never understand comparing code to art. Not the first time I'm seeing it but for me it couldn't be further apart.

There is no best way to make a drawing. There is no best way to make a movie. There is no best way to tell a story. There is no best way to make a painting. There is no best way to create a song. ... There is (almost?) always a best way to do a piece of code. Code has nothing to do with emotions. I'm not trolling I truly don't get it, like at all.

Re: Anti Mediocracy Manifesto for Software Development

#55
post #25
post #8

These lines sound like a recipe for scope/feature creep and never ending development process. >Never do requirement analysis. Never write technical requirements or functional ones. If you do, you have already failed. In that case, how do you know when the software is finished and your contract has been fulfilled? >Creative solutions are often holistic in nature, driven by first-hand experience, discussion, interactio…

Tbh I know what he is saying. Software that is speced up by BA's and driven by their requirements tends to end up being really bad software. The best software is built up over time as demand arises for those features. Create the feature requests as they are required and implement the requests. I think one of the major causes of why this type of thinking ends up building bad software is that BAs include literally ever…

Sounds like the flaw is having business analysts do the requirements analysis instead of systems engineers. It also assumes you are creating a standalone application and not a piece of a larger system.

Re: Anti Mediocracy Manifesto for Software Development

#57
post #8

These lines sound like a recipe for scope/feature creep and never ending development process. >Never do requirement analysis. Never write technical requirements or functional ones. If you do, you have already failed. In that case, how do you know when the software is finished and your contract has been fulfilled? >Creative solutions are often holistic in nature, driven by first-hand experience, discussion, interactio…

you missed the point: The point is, if the requirements for a piece of code are so complex that you NEED to write a requirement analysis, that you NEED to do anything other than plan out your code, and write it, than your software is already too complicated. You need to narrow the scope. Lots of small systems is better than one large system.

There are domains wherein the software is inherently this complex and requirements analysis is unavoidable. This is particularly true when decomposing one large system into small systems. Someone needs to be the systems engineer that determines how the pieces couple together and how overall system functionality is divided into the pieces.

Requirements analysis is also critical when the software is coupled to particular hardware or a particular process.

Re: Anti Mediocracy Manifesto for Software Development

#58
post #8

These lines sound like a recipe for scope/feature creep and never ending development process. >Never do requirement analysis. Never write technical requirements or functional ones. If you do, you have already failed. In that case, how do you know when the software is finished and your contract has been fulfilled? >Creative solutions are often holistic in nature, driven by first-hand experience, discussion, interactio…

you missed the point: The point is, if the requirements for a piece of code are so complex that you NEED to write a requirement analysis, that you NEED to do anything other than plan out your code, and write it, than your software is already too complicated. You need to narrow the scope. Lots of small systems is better than one large system.

Yeah, sorry, but real life software doesn't work that way. Real life software is often inherently complex.

Re: Anti Mediocracy Manifesto for Software Development

#60

Some of you seem to be missing the satire here.

>Some of you seem to be missing the satire here.

IMO, you're probably overthinking it. None of the other writings on the rest of the author's site suggests that any of the articles are meant to be satire or even that the author is capable of satire at this level.

Post reply on HN