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.
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.
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.
> 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.
> 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.”
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.
> 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.
but the problem shows up when the customer doesn't believe you when you say you're 5x faster.
They compare you against another consultant, who might be cheaper, and say that you're just over charging.
Therefore, you should be charging the going rate, but do it 5x faster, and have free time to take on more projects. You could also deliver earlier, and then have a charge for change requests (which invariably come).
I mean, of course it’s up to you to make potential clients believe you. If you give me no reason whatsoever to think you’re a competent and accomplished contractor, why would I “believe” you?
There's only so much expertise you can put into "a few strokes". Charging for 5 weeks to do something in 1 week, that is high quality and still needs support? Go for it. The story about charging $9999 to know exactly where to mark the problem that everyone else couldn't solve, $1 for the mark itself? Great. But plenty of people could make an "unmistakable" Picasso that's only a few strokes. If that sketch is worth even a percent of the asking price, it's based on his fame. It has the value of an autograph, not the value of 40 years of practice.
I'd say either you bill by the hour (and you bill for the hours where you did something dumb and got nothing done, but you don't bill for the hours you didn't have to spend because you did something smart), or you bill by the project/deliverable which means you bill for every change request, whether it takes many hours because you didn't anticipate it or few hours because you did. Whichever choice you make cuts both ways.
I think you're looking at this completely the wrong way.
This is like saying you'll only pay your brain surgeon for four hours work because that is as long as the operation you require will take. But that four hour operation is built on a lifetime of training and skill.
The value that you provide the customer is the metric from which you should be deriving your billing. If someone else provides an equally effective solution but takes an order of magnitude more time to deliver it, then you are just that much more efficient.
> Should you be charging clients for time that you didn't have to spend because you made some good decisions upfront?
In a lot of consulting gigs, you don't do time-and-material. You do fixed price. So, you invested _your_ time and you took the risk of creating such solution, even when the client sweared that some requirement would never change.
In most contracts, if you, as the contractor, make a mistake, it's up to you to fix it. If you trusted the client, you'd have to charge 10 at any CR instead of 1. So, it makes perfect sense to charge at least 5, or maybe even 10.
(ofc if you're working time&material or in an agile/flexbile fashion where there's trust between client and consultant, this doesn't apply)
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.
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.
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.
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.
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.
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.
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.
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.
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.