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.

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.

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.

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"

If we forced everyone to switch to Haskell, do you think this would really be any different? People would still do the bare minimum to implement the latest user stories, because that is literally what the boss is paying for.

We force everyone to switch to Haskell. OK. Even the fair-to-mediocre programmers? Yes. Who tend to program by copypasta and change stuff until it gets the right answer? Yes.

Run away. Run far, far away. You don't want to see what "design patterns" and urban legends these people layer on top of Haskell to make it intellectually manageable.

I remember being a sophmore in college and I understood the basics of haskell (not really monads yet) and we worked in groups. My partner was very intelligent, but didn't have a grasp on the language at all.

For the final project, we had a problem that I didn't understand well, but he couldn't use the language effectively. We ended up having him work out the problem incorrectly in a shared notepad and I would refactor his broken code into something that worked. It was a mess. I'm pretty sure I've seen worst things you can possibly build in haskell -- and they are bad.

> You don't want to see what "design patterns" and urban legends these people layer on top of Haskell to make it intellectually manageable.

Do share examples if you have them.

I think the point is to not force any single paradigm. OOP is what is being forced today, but it would also be bad if the industry forced functional programming. Large programs typically call for multiple styles of programming. One piece may suit an imperative style, another functional, another logic/relational, another object-oriented, etc. In general, I think OOP is nearly always the wrong tool, though.

I'm in university right now and there is an object-oriented programming course (which is required by most other advanced courses), but no functional programming course. That shows how skewed the industry is. It's a pretty forward-thinking university as well.

OOP is sometimes the right tool, but most times it definitely is not. It's important to be able to know your tools and choose the right one. The current situation is disappointing though.

In Haskell? I'm afraid the bare minimum is the most abstract possible engine with business rules added on as data or high level function application.

But I'm not really disagreeing. It's just that those people will spend months and months on some stupid repetitive concrete code, while the smart way would take a week, and the OOP way would take 3 weeks in Java.

Are you saying you prefer example 2, in the comment you replied to?

In Java-land, this seems to be the kind of thought process referred to as "engineering". Read the code in any random Spring project, for example.

Personally, I prefer writing simple code for the job at hand, and, yes, refactoring when I find two or more places where the same code can be re-used. And even though I develop mostly in Java, the most "functional" solution is generally the one with the least complexity, and easiest to debug.

I definitely hate solution number 2.

One major problem I find with OOP is that it is often requiring refactoring. Every time you shove something into an object you actually take away from it.

One thing that greatly inspires me from Haskell is that it does have design patterns, but they are based on category theory. Math is the ultimate tool. I don't think we can accidentally "create" something as richly descriptive for describing the benefits and problems for using a certain pattern.

I'm having trouble understanding your definition of "refactoring", then.

When I refactor, it's almost always to eliminate repetition and make the code more concise. But doesn't the same thing happen in a functional program? If you find the same code twice, refactor into a single function.

I'm getting at the idea of having to rearrange the code inside classes because your original assumptions have changed. Sometimes this involves moving stuff between classes. This is especially messy if the class has any member variables or relies on private functions.