How to stop functional programming

Re:How to stop functional programming by JustSomeNobody on Tuesday February 23, 2016 @10:50AM (#11159682)

Not only that but there's this obsession(?) with doing things as quickly as possible. No matter what task it is on a story it is always, "should only take a couple hours". NO! Stop! You're training your managers to think that every task can be done in two hours! Give yourself some time to stop and reason about the code you're writing AND integrating into the larger system. Be patient. Be thoughtful. Be careful.

Now, I'm not advocating taking a 3 days to do this. But stop with the "couple hours" crap.

[ Parent | on HN ]

Re:How to stop functional programming by FilterSweep on Tuesday February 23, 2016 @11:32AM (#11160028)

Do note that in a corporate setting, this obsession is primarily due to Project managers, Implementations, and even Sales who don't have a hand in the actual development expecting projects to be finished quickly, and to "just work."

When these groups hear the words "Agile Development" which was a common buzzword in recently past years - they take it literally - "moving quickly."

I completely agree, and it is often the cause of absolutely unnecessary bugs, stress, inefficient code, and developers often precipitate this bad obsession. But it comes from, and is ingrained from, somewhere else.

[ Parent | on HN ]

Re:How to stop functional programming by hnal943 on Tuesday February 23, 2016 @01:38PM (#11161156)

I think it's easy to blame others, but programmers are optimistic by nature and bad at estimating. Also, I think all of us have had the opposite scenario where a request comes in from a business-minded person that they think will take forever and it turns out to be trivial. It feels great to do a lot of good very quickly, independent of what the project schedule says.

[ Parent | on HN ]

Re:How to stop functional programming by vfc1 on Wednesday February 24, 2016 @04:22AM (#11165519)

This is so painfully true. Sprints are organized to have very little time for technical debt and refactoring. From time to time there is a technical debt sprint that addresses all the wrong issues.

But there is plenty of time to endlessly maintain crap code that should simply be rewritten. Plenty of hours to endlessly debug hard to debug code, for that time is not an issue. But to rewrite something that really needs to be rewritten, there is no budget for that.

In the end it takes much more time to maintain bad code than to rewrite it, the users have bad user experience and there are endless bugs.

Software factories are agile only in the view of agile consultants. This much process where developers are basically managed like assembly line workers is the antithesis of agile: agile should be about collaborating together to solve a problem with very little process: "Individuals and interactions over processes and tools"

[ Parent | on HN ]