3 ms·

> That is precisely the job of responsible management: to stop technical teams from using expensive technologies, that are not only unproven, but hardly have an

by pka 10y ago

> That is precisely the job of responsible management: to stop technical teams from using expensive technologies, that are not only unproven, but hardly have any actual anecdotal information at all. The precise difference between management and developers is that management sees the bigger picture. In most cases management isn't qualified to make technical decisions. Managers rarely see the bigger picture. I've worked on a Haskell project that worked, never crashed, was lightning fast and was meeting deadlines for new features without a problem. Then higher management decided to throw away probably around 7-10 man-years and rewrite the whole thing in Java, quite literally "just because Java". We even had a consultant from FP complete come over to take a look at our codebase and talk in front of management about the advantages of a mature codebase in Haskell. Management didn't even come. Abandoning Haskell, in my case, had absolutely nothing to do with its technical merits and everything to do with incompetent management. When I left one year after they started rewriting the project in Java (I was staying to help maintain the Haskell code while the transition was happening) everything was buggy as hell, slow and unmaintainable. Not to mention that half the Java guys they hired had already left again.

pron 10y ago
First, given the large effort involved and how much you wanted Haskell to succeed, I assume you carefully collected lots of metrics. By publishing them you could actually do Haskell and the software community at large some actual good other than just complain about incompetent management (and I've whined about management, too). You may have missed the chance in that company, but your well-researched report is sure to convince some others, so that's not a total waste at all. Second, such incompetence often works in the other direction, too, usually in companies where incompetence takes a different form, which is why a little actual information would be nice. Your technical report about a 7-10 man-year Haskell-and-then-Java project would make a great contribution! For an experiment of such non-trivial effort, and given that the project was later re-written in Java, you may even find a prestigious publication to publish your report.
- pka 10y ago
  Back then I would have loved to do it because of the exact reasons you mention (i.e. it would have been a perfect case study of the same project implemented in two different languages), but unfortunately I wasn't at liberty to disclose specifics. All I could do is collect metrics like lines of code and intentionally vague experience reports from former colleagues who are still there, but I guess that's hardly gonna convince anybody.

by pka 10y ago

pron 10y ago

First, given the large effort involved and how much you wanted Haskell to succeed, I assume you carefully collected lots of metrics. By publishing them you could actually do Haskell and the software community at large some actual good other than just complain about incompetent management (and I've whined about management, too). You may have missed the chance in that company, but your well-researched report is sure to convince some others, so that's not a total waste at all. Second, such incompetence often works in the other direction, too, usually in companies where incompetence takes a different form, which is why a little actual information would be nice. Your technical report about a 7-10 man-year Haskell-and-then-Java project would make a great contribution! For an experiment of such non-trivial effort, and given that the project was later re-written in Java, you may even find a prestigious publication to publish your report.

pka 10y ago
Back then I would have loved to do it because of the exact reasons you mention (i.e. it would have been a perfect case study of the same project implemented in two different languages), but unfortunately I wasn't at liberty to disclose specifics. All I could do is collect metrics like lines of code and intentionally vague experience reports from former colleagues who are still there, but I guess that's hardly gonna convince anybody.