• she/her

Principal engineer at Mercury. I've authored the Dhall configuration language, the Haskell for all blog, and countless packages and keynote presentations.

I'm a midwife to the hidden beauty in everything.

πŸ’– @wiredaemon


discord
Gabriella439
discord server
discord.gg/XS5ZDZ8nnp
location
bay area
private page
cohost.org/newmoon

A very common mistake I see a lot of engineering teams make is say something along the lines of "If we create this framework X then the less technical users of this framework will be able to thoughtlessly churn out a bunch of code in this framework and it will be great and there won't be any problems and we move onto the next project". This literally never works out (at least, not in the way that people think it will).

In the best case scenario, your users will churn out a large amount of code using your framework (which is exactly the outcome you hoped for!) and that huge amount of code will push the boundaries of what your framework is capable of (like performance, compilation speed, or features). The larger your user base is the greater the demand will be to improve your framework in a myriad of ways.

In the worst case scenario your users will find increasingly inane ways to do things wrong with your framework despite your best efforts and you will be expected to clean up their mess because you very likely sold the project to management on the premise of "our users are not going to have to think".

… and this process will literally never end; the project will never be in a "done state" and require permanent staffing.

Personally, I'm fairly "anti-framework" by default because in my experience most frameworks are essentially software engineering organizations attempting to "launder" skilled labor as unskilled labor. Software engineering organizations like to pretend that they can somehow make productive use of a large pool of unskilled labor (less technical users in this case) but in reality this pool of unskilled labor will quickly become blocked without continuous assistance from a pool of skilled labor (engineers supporting the framework in this case).

I do think there are some situations where this skilled/unskilled labor division makes sense, but typically not on the scale of a software engineering organization. I personally only think on the scale of an open source ecosystem do you get enough of an economy of scale that this sort of divide can pay off.


You must log in to comment.

in reply to @fullmoon's post:

this is exactly what happened at my last job! our whole product was a database auditing suite that was supposed to be for nontechnical users. we could not go two days without a support call because somebody had constructed a query that made 2 services crash with half a dozen button clicks.

It's also extremely telling that frameworks don't ever seem to go anywhere. They all become the same general thing, solving the same problems and nothing new. Thanks so much, company, for giving me a generator to write the easiest code in the project, and then let me secure this monstrosity for myself...