blah blah blah more things here
From my experience fundraising in Haskell, companies who use it all seem to have suffered from the same two flavors of problem:
-
A rockstar comes in, dumps mindblowing code everywhere that dazzles the rest of the team and fools the product leads with pseudo-productivity until the rockstar leaves or finally wakes up. Cue the rest of the team death-marching for the next year or few years as the team attempts to juggle feature additions with excising or unraveling the impenetrable yarn-tangle of semantic misdirection.
-
An especially productive senior or team lead spends their time on refactoring and generally spinning their wheels with respect to product delivery, and then fails to deliver on time, or at all. Cue the rest of the team struggling to keep up with the refactors. The team's knowledge of the state of the product suffers, confusion about goals sets in, the senior/lead effectively becomes an anti-team player, throwing curveballs at the rest of the team until the project fails or the others leave in anger.
I've actually encountered the same phenomena across 6 separate Haskell companies now in my fundraising work. The good news is that these are common and solvable problems. The bad news is that this isn't a class of problem that can be solved by hiring better developers. Well, actually, that's a lie. It can. But you haven't solved the problem in the longterm, and it does nothing to alleviate your operational risk, because the possibility of hiring the same person persists. No, this is an even deeper problem: hiring and training better Haskell managers.
The secret to delivering a Haskell project, from personal experience, boils down to having managers who can spot the unique flavor of spinning wheel associated with Haskell development. This is not in general a Haskell problem, but one of a brand new, bright and shiny technology entering into the industrial sphere, which no one knows what to do with. Combine non-technical management with the fact that many Haskellers enter the field as pointy-headed academics who are very junior when it comes to software delivery, but particularly convincing when explaining why feature X is the one the team wants, and you have a recipe for disaster. Without guardrails in the form of Haskell-savvy, delivery-oriented management and seniors, any project is going to be doomed to fail. This is a failure of management to properly manage a project, assign deadlines, deliver key deliverables, and to generally do the people management needed to get these things done. All because the shiny thing is so shiny that they've made the most critical of critical errors: they let the developer run wild with development! You can hardly blame Haskellers for not succeeding when there are so many shiny toys to engage. Taste and discipline are learned, but there seems to be no one willing to teach it to them!
blah blah blah more things here
When it comes to the particular flavor of what was used to tank a project, a few of them complain about Nix, but by far the majority I've worked with sink by means of overzealous application of GADTs, TypeFamilies, and effect systems. The keyword here is overzealous. These things are great in and of themselves; TF and GADTs obviously solve a real problem. But, like the C++ dev who uses templates for fizzbuzz, most of the time they are the cannon used to swat the fly. All I'm advocating here is to use a flyswatter instead, or, if there is team/management/lead consensus that this is particularly large fly, go ahead and use the cannon. Every single industrial programming language on the planet has a set of best practices and a core sublanguage that people adhere to when building projects. Every language has unsafe, overpowered, or misapplied constructs that need to be carefully considered before their use. Haskell is no different. However, the Haskell community has not settled on such a sublanguage, nor on how best to decide upon one, and to do so is almost certain blasphemy in one direction or another. Simple Haskell is one such movement that comes to mind, but there are others, such as boring haskell.
Haskell is special mainly because the company that chooses Haskell has done so with awareness of Haskell as a differentiating choice. Thus, choosing Haskell often says something about the company choosing to do so. This includes:
- A belief that using Haskell will attract better developers/supercharge your project
- A belief that the use-case will benefit from Haskell's unique features
- The company has Haskellers in leadership
- The company can hire from an already-existing network of Haskell talent
In other words, nobody "stumbles into" forming a Haskell shop, but if a company is betting the farm on #1 without any of the other qualities, they are certainly going to stumble, and probably fail. Haskell presents unique challenges to an engineering team that have to be factored into roadmaps, like extra work for missing integrations or CI/CD setup, and while Haskell has excellent engineers, there simply aren't as many experienced senior engineers to hire.
#2 is true sometimes but not as often as the lore might suggest. Yes, Haskell is excellent for PL work, formal methods etc, but even projects with this focus often have a fair amount of "vanilla engineering" that needs to get done as well. A project can always have the "Haskell core" to just focus on the lofty stuff, but this limits the reach of the Haskell group and its influence in the organization and can create divisions even.
This is why #3 -- Haskellers in leadership -- can make a big difference. A shop that kicks off with an experienced Haskeller CTO has a much better chance of success, assuming the leader
- Believes in Haskell as a general-purpose application language and appreciates its unique strengths as an attractive tradeoff for its weaknesses vs other general-purpose languages.
- Does not think hiring Haskell developers is a magic bullet or somehow easier than hiring for another language.
It's OK to still be biased to Haskell programmer talent, and maybe the use-case is particularly Haskell-friendly, but the above are still important for success.
#4 often comes with #3. But if you don't have Haskell technical leadership, fix that with #4: ask around to try to hire the most experienced Haskell team lead you can, and then empower them to steer the ship. With many programmers, but perhaps more with Haskell, it's important that the lead be respected as an authority: they don't have to be smarter than other programmers but they need to able to call them out on missed deliveries and other pitfalls described elsewhere herein, and understand the choices taken by the team.
blah blah blah more things here
At risk of being called a hypocrite (my current project is a higher-order and kind-indexed functor library which makes use of all of the shiny things that I just mentioned), I tend to agree that fancy types shouldn't be in the grab-bag of tools without guardrails. Those guardrails should come in the form of a senior lead who can go toe-to-toe with a rockstar or hyper-productive developer and vet their use of those tools and grant them novelty bonus budget. This is all a very healthy conversation, despite what I think it may look like from all of the rabble you see in the comments section of these kinds of blog posts. Every single language on the planet has to go through the conversation that lays out a set of core best practices, and every team needs to understand what those best practices are so they can understand how much novelty they're budgeting by accepting particular extensions, technologies, and development styles.
blah blah blah more things here
I might a suggest a section after "Haskell is not special" called
Haskell Is Special
Haskell is special mainly because the company that chooses Haskell has done so with awareness of Haskell as a differentiating choice. Thus, choosing Haskell often says something about the company choosing to do so. This includes:
In other words, nobody "stumbles into" forming a Haskell shop, but if a company is betting the farm on #1 without any of the other qualities, they are certainly going to stumble, and probably fail. Haskell presents unique challenges to an engineering team that have to be factored into roadmaps, like extra work for missing integrations or CI/CD setup, and while Haskell has excellent engineers, there simply aren't as many experienced senior engineers to hire.
#2 is true sometimes but not as often as the lore might suggest. Yes, Haskell is excellent for PL work, formal methods etc, but even projects with this focus often have a fair amount of "vanilla engineering" that needs to get done as well. A project can always have the "Haskell core" to just focus on the lofty stuff, but this limits the reach of the Haskell group and its influence in the organization and can create divisions even.
This is why #3 -- Haskellers in leadership -- can make a big difference. A shop that kicks off with an experienced Haskeller CTO has a much better chance of success, assuming the leader
It's OK to still be biased to Haskell programmer talent, and maybe the use-case is particularly Haskell-friendly, but the above are still important for success.
#4 often comes with #3. But if you don't have Haskell technical leadership, fix that with #4: ask around to try to hire the most experienced Haskell team lead you can, and then empower them to steer the ship. With many programmers, but perhaps more with Haskell, it's important that the lead be respected as an authority: they don't have to be smarter than other programmers but they need to able to call them out on missed deliveries and other pitfalls described elsewhere herein, and understand the choices taken by the team.