8 ms·

It's funny how projects grow like this organically. Perhaps burned by experience, one time I implemented a mini-language for specifying some business logic tha

It's funny how projects grow like this organically. Perhaps burned by experience, one time I implemented a mini-language for specifying some business logic that I knew—just knew—that our client would change his mind on a dozen times and not understand the half of the ramifications of his requests and would only arrive at the solution he really wanted by trial-and-error. Was the little language I made as complex as a "real" compiler? Goodness no. Was I happy to have a flexible language-based solution? True to my predictions, I did get many, many logic change request and handled them with ease. Yes, I was very happy after that.

alanfranz 3y ago
Now the question is: did you make your client pay for each request _just as if you didn’t build such dsl_? In my experience, most developers-as-consultants aren’t good at that. So, when we’re (rightfully) late, we probably reduce our margins. When we do a great job, we don’t make the client pay for his own mistakes.
- jimvdv 3y ago
  You are right most developers are not very good at that. I think it’s important to stress that this goes both ways. You should not cut your margins if you take longer, but I also think it is a little unethical to bill more hours than one spends no? At least if you have a clear agreement to bill by the hour.
  - awkward 3y ago
    The way to ethically handle this is to have a clear and contractual minimum number of billed hours in a day. That will get you paid well for built in efficiencies like OP mentioned, and keep you paid fairly on more substantial change requests.
  - thfuran 3y ago
    It's outright fraud. It's clearly unethical. But your billing shouldn't be strictly hourly if you're building tooling to speed up your work.
    - deleted 3y ago
      [deleted]
  - derefr 3y ago
    What you’re saying is that it’s inherently unethical (to yourself!) to accept hourly billing for work the whole point of which is exponential automation.
- tshaddox 3y ago
  > did you make your client pay for each request _just as if you didn’t build such dsl_? I'm not exactly sure what you're asking. Should you be charging clients for time that you didn't have to spend because you made some good decisions upfront? That strikes me as odd. If you agreed upfront on the cost for a certain end result, then sure, charge that full agreed-upon amount even if it took you less time than expected. But it seems odd to say "this change only took me an hour, but it would have taken 10 hours if I had made worse choices in designing this system, therefore I'm going to bill you 10 hours." After all, there's always a hypothetical situation where any given change could have taken arbitrarily more time if you had made worse decisions in the past.
  - xelxebar 3y ago
    > Should you be charging clients for time that you didn't have to spend Yes! Completing a job or task in 1 week is more valuable than completing it in 5. The lion's share of value we provide as developers and consultants is not output but battle-tested intuitions that let us navigate the giant solution space, so bad decisions we don't make is definitely hard-earned value servicing the client. A man once interrupted Picasso at his evening meal. Pulling a napkin from his pocket, the man said, “Could you sketch something for me? I’ll pay you for it. Name your price.” Picasso took a charcoal pencil from his pocket made a rapid sketch of a goat. It took only a few strokes, yet was unmistakably a Picasso. The man reached out for the napkin, but Picasso did not hand it over. “You owe me $100,000,” he said. The man was outraged. “$100,000? Why? That took you no more than 30 seconds to draw!” Picasso crumpled up the napkin and stuffed it into his jacket pocket. “You are wrong,” he said, dismissing the man. “It took me 40 years.”
    - beachy 3y ago
      That tired old Picasso story only works because the customer was not told up front how long the job was going to take. As a consultant, you are typically billing by the hour (or day) and you will most likely be giving the client some kind of estimate/quote as to how long the job will take, and your rate, and hence the cost to them. You might very well be able to do the job in one week rather than 5, but it would be dishonest to tell the customer it will take 5, then complete it in 1, but still bill them for 5. Instead you should tell the customer that it would normally take 5, but you are able to do it in 1, so you are charging 5x (or 3x or whatever) the going rate.
- ashton314 3y ago
  I was a student working as a web developer in an on-campus dev shop, and our client was one of the entities on campus. Thus, our incentive was to get a working thing as fast as possible that took as little maintenance as possible. I got bored on the job occasionally, so I'd try experiments on how elegantly I could implement something.
mjr00 3y ago
Depends on the project, but if you're handling these client requests anyway, this is not the best solution IMO, at least not for cloud/SaaS. The best solution is to have a good deployment process in place that makes it easy for you to make business logic changes using your language of choice, rather than building and maintaining a secondary language that is understood only by you. No need to create a DSL or compiler or worry about maintenance when you're just using the same tooling as everything else you use. Seen way too many times in my career developers who build the fun, interesting solution (DSL/compiler/parser) instead of the boring, but far more practical solution of fixing their deployment processes.
- yesbutum 3y ago
  [dead]
- Karellen 3y ago
  When the project I was working on had this problem, the request to build a DSL was based on the idea that each client ought to be able to make their own changes. The client shouldn't have to know a "full" programming language, but a "sufficiently simple" DSL isn't that much more than a config file format, right? They can learn how to make small changes themselves if the language is easy enough, can't they? I tried to convince management that this wouldn't work. If nothing else, because our DSL was invented in-house, there was no-where else the client could find answers on how to make the changes they wanted. There would be no hits on Google, no answers on StackOverflow, no random client employee who happened to have some relevant tech knowledge. If they had any questions at all, they'd need to come to us, and we'd end up writing the changes for them anyway. And, as you point out, we already had a perfectly good programming language - the one everything else (including the DSL) was written in.
toyg 3y ago
I cut that particular gordian node, once, by simply embedding a JS engine, and explaining to them (and documenting) the bare minimum of the language that they needed to achieve their objectives. After a week of getting to grip with it, they loved it so much that they kept it into production for years, happily tweaking scripts as they needed. I should have charged them more than I did.
- Const-me 3y ago
  I did it with VBScript, Python, LUA, and in .NET both with and without C# compiler frontend. All these methods worked fine for my use cases.
- intelVISA 3y ago
  > I should have charged them more than I did. That's the problem isn't it? Unless it's SaaS you don't want to solve a problem too well...
mikepurvis 3y ago
What were the requirements that led to implementing your own language vs embedding lua?
duxup 3y ago
I’ve passed on using many a package that I thought was too complex for for my needs only to find myself effectively writing my own version/ learning why that other package is the way it is. Suddenly the API looks oddly familiar…. OMG…
- mcny 3y ago
  Yes, everything looks simple and straightforward from a distance. As you get closer, you are faced with dozens of not hundreds of decisions that you need to make. If you're good, you won't be stuck with analysis paralysis.

alanfranz 3y ago

Now the question is: did you make your client pay for each request _just as if you didn’t build such dsl_? In my experience, most developers-as-consultants aren’t good at that. So, when we’re (rightfully) late, we probably reduce our margins. When we do a great job, we don’t make the client pay for his own mistakes.

jimvdv 3y ago
You are right most developers are not very good at that. I think it’s important to stress that this goes both ways. You should not cut your margins if you take longer, but I also think it is a little unethical to bill more hours than one spends no? At least if you have a clear agreement to bill by the hour.
- awkward 3y ago
  The way to ethically handle this is to have a clear and contractual minimum number of billed hours in a day. That will get you paid well for built in efficiencies like OP mentioned, and keep you paid fairly on more substantial change requests.
- thfuran 3y ago
  It's outright fraud. It's clearly unethical. But your billing shouldn't be strictly hourly if you're building tooling to speed up your work.
  - deleted 3y ago
    [deleted]
- derefr 3y ago
  What you’re saying is that it’s inherently unethical (to yourself!) to accept hourly billing for work the whole point of which is exponential automation.
tshaddox 3y ago
> did you make your client pay for each request _just as if you didn’t build such dsl_? I'm not exactly sure what you're asking. Should you be charging clients for time that you didn't have to spend because you made some good decisions upfront? That strikes me as odd. If you agreed upfront on the cost for a certain end result, then sure, charge that full agreed-upon amount even if it took you less time than expected. But it seems odd to say "this change only took me an hour, but it would have taken 10 hours if I had made worse choices in designing this system, therefore I'm going to bill you 10 hours." After all, there's always a hypothetical situation where any given change could have taken arbitrarily more time if you had made worse decisions in the past.
- xelxebar 3y ago
  > Should you be charging clients for time that you didn't have to spend Yes! Completing a job or task in 1 week is more valuable than completing it in 5. The lion's share of value we provide as developers and consultants is not output but battle-tested intuitions that let us navigate the giant solution space, so bad decisions we don't make is definitely hard-earned value servicing the client. A man once interrupted Picasso at his evening meal. Pulling a napkin from his pocket, the man said, “Could you sketch something for me? I’ll pay you for it. Name your price.” Picasso took a charcoal pencil from his pocket made a rapid sketch of a goat. It took only a few strokes, yet was unmistakably a Picasso. The man reached out for the napkin, but Picasso did not hand it over. “You owe me $100,000,” he said. The man was outraged. “$100,000? Why? That took you no more than 30 seconds to draw!” Picasso crumpled up the napkin and stuffed it into his jacket pocket. “You are wrong,” he said, dismissing the man. “It took me 40 years.”
  - beachy 3y ago
    That tired old Picasso story only works because the customer was not told up front how long the job was going to take. As a consultant, you are typically billing by the hour (or day) and you will most likely be giving the client some kind of estimate/quote as to how long the job will take, and your rate, and hence the cost to them. You might very well be able to do the job in one week rather than 5, but it would be dishonest to tell the customer it will take 5, then complete it in 1, but still bill them for 5. Instead you should tell the customer that it would normally take 5, but you are able to do it in 1, so you are charging 5x (or 3x or whatever) the going rate.
ashton314 3y ago
I was a student working as a web developer in an on-campus dev shop, and our client was one of the entities on campus. Thus, our incentive was to get a working thing as fast as possible that took as little maintenance as possible. I got bored on the job occasionally, so I'd try experiments on how elegantly I could implement something.

mjr00 3y ago

Depends on the project, but if you're handling these client requests anyway, this is not the best solution IMO, at least not for cloud/SaaS. The best solution is to have a good deployment process in place that makes it easy for you to make business logic changes using your language of choice, rather than building and maintaining a secondary language that is understood only by you. No need to create a DSL or compiler or worry about maintenance when you're just using the same tooling as everything else you use. Seen way too many times in my career developers who build the fun, interesting solution (DSL/compiler/parser) instead of the boring, but far more practical solution of fixing their deployment processes.

yesbutum 3y ago
[dead]
Karellen 3y ago
When the project I was working on had this problem, the request to build a DSL was based on the idea that each client ought to be able to make their own changes. The client shouldn't have to know a "full" programming language, but a "sufficiently simple" DSL isn't that much more than a config file format, right? They can learn how to make small changes themselves if the language is easy enough, can't they? I tried to convince management that this wouldn't work. If nothing else, because our DSL was invented in-house, there was no-where else the client could find answers on how to make the changes they wanted. There would be no hits on Google, no answers on StackOverflow, no random client employee who happened to have some relevant tech knowledge. If they had any questions at all, they'd need to come to us, and we'd end up writing the changes for them anyway. And, as you point out, we already had a perfectly good programming language - the one everything else (including the DSL) was written in.

toyg 3y ago

I cut that particular gordian node, once, by simply embedding a JS engine, and explaining to them (and documenting) the bare minimum of the language that they needed to achieve their objectives. After a week of getting to grip with it, they loved it so much that they kept it into production for years, happily tweaking scripts as they needed. I should have charged them more than I did.

Const-me 3y ago
I did it with VBScript, Python, LUA, and in .NET both with and without C# compiler frontend. All these methods worked fine for my use cases.
intelVISA 3y ago
> I should have charged them more than I did. That's the problem isn't it? Unless it's SaaS you don't want to solve a problem too well...

mikepurvis 3y ago

What were the requirements that led to implementing your own language vs embedding lua?

duxup 3y ago

I’ve passed on using many a package that I thought was too complex for for my needs only to find myself effectively writing my own version/ learning why that other package is the way it is. Suddenly the API looks oddly familiar…. OMG…

mcny 3y ago
Yes, everything looks simple and straightforward from a distance. As you get closer, you are faced with dozens of not hundreds of decisions that you need to make. If you're good, you won't be stuck with analysis paralysis.