Customers buy solutions. They don't buy specifications documents, they don't buy elegant code, they don't buy automatic test coverage. All of these are useful only as long as they help you deliver solutions to customers faster. Any effort more is better spent on actually building solutions for customers. Maintainability is nearly top priority; real top priority is to have something to maintain in the first place.
Corollary: quick-and-dirty exist for a reason. It's easy to say that quick-and-dirty is just dirty, and it's true: in the long run, quick-and-dirty takes longer than the-right-thing. But, there is a but: time doesn't always have the same value! Time just before a deadline is much more precious than the time after the deadline, when you can relax a bit and fix things before the next stress wave. Have it working and ship it now; we'll get it in better shape next week, while the customer will be happy playing with their new toy.
And telling a customer that what they want a) won't work and b) is not cost-efficient to build can also be a good idea.
You might "lose" a customer, but word will travel that you won't build crap that wastes clients money. Which in turn might bring in more business later on.
Also when building a quick-and-dirty solution, make it LOOK dirty.
A fancy UI with a janky back-end will look like polished software to the customer, keep the user experience in sync with the code progress.
If your backend is WIP, the UI should be only unstyled plain HTML components when demoing it to the customer. If there is no UI, the backend should print all kinds of janky-lookig debug messages that make it clear it's not ready for production.
> Absolutely agree. It can be so difficult to explain to a customer why you've put together a prototype in 6 weeks but then struggle to explain why it'll take another 3 years to complete
> quick-and-dirty exist for a reason. It's easy to say that quick-and-dirty is just dirty, and it's true: in the long run, quick-and-dirty takes longer than the-right-thing
I've started to view this as "quick and dirty pays the bills for me to clean up later".
Yes, it'd be great to have an elegant solution right off the bat - but that's almost always going to take more time/effort. There's also a good chance what you build is completely wrong, so it might get thrown away.
Of course, there are exceptions to this. Particularly, for well-known, well defined things or safety critical things.
On that line, it's a good idea to optimize for the integral of business value delivered. It's better to deliver something partial and hack-y quickly so the business can start enjoying it rather than delivering all at once. Not to mention the invaluable interim feedback gathered from your users in the meantime.
Also, it's not enough to build something; you need to make sure people are using it, and using it right, or else you leave value on the table. Run trainings, monitor user engagement, talk to your users. Make sure what you built is used to its full potential and delivers the maximal impact.
Oh, how I wish the companies I work with did that. When I find one that does I'm immediately loyal for life... Or, well, until they IPO / exit - which, in my now repeated experience, is when they stop paying attention.
Definitely "documentation beyond "how to use this" is going to cost you more" is a policy I do for side business outside my day job. That said I do try to spend a bit of extra time to make the API easy to understand, well named, and expose only those things they need. But I just consider those good coding and time well spent when I have to revisit it. What lies beneath is not always be so pretty, depending on what the customer is paying.
Customers buy solutions. They don't buy specifications documents, they don't buy elegant code, they don't buy automatic test coverage. All of these are useful only as long as they help you deliver solutions to customers faster. Any effort more is better spent on actually building solutions for customers. Maintainability is nearly top priority; real top priority is to have something to maintain in the first place.
Corollary: quick-and-dirty exist for a reason. It's easy to say that quick-and-dirty is just dirty, and it's true: in the long run, quick-and-dirty takes longer than the-right-thing. But, there is a but: time doesn't always have the same value! Time just before a deadline is much more precious than the time after the deadline, when you can relax a bit and fix things before the next stress wave. Have it working and ship it now; we'll get it in better shape next week, while the customer will be happy playing with their new toy.