4 ms·

CDD is not a bad way to write software at all. In fact, companies that do this are probably more successful than not. Your customers are your source of revenu

CDD is not a bad way to write software at all. In fact, companies that do this are probably more successful than not. Your customers are your source of revenue, 'what they want' is good for your business :) In the early stages of a company, before mass market adoption, it makes sense for companies to please whoever they can before 'lift off' into broader adoption. So many companies got their start this way. Microsoft, Oracle etc.. From an architectural standpoint, it may sometimes seem 'impure' but then you really do have to ask yourself what you are building and why :).

vlozko 10y ago
I largely agree with you. The challenges with this largely fall on the business side. I've once worked at a place where a customer agreement was structured in such a way that tied up our development and QA resources for resolving issues for them that weren't due to a fault on our product. For a small company of ~10 developers, we spend an awful amount of time tying up resources on tracking down issues that ended up being bugs in their own software; they just happen to discover them while using our product. And we really didn't get all that much money from them, either. It's not uncommon for a small startup to tie themselves up with a poor customer agreement for the sake of name recognition or misplaced hope in the agreement opening doors down the road.
metaphorm 10y ago
CDD is when a customer is convinced to buy very expensive software that amounts to nothing more than a cosmetic upgrade to their existing broken process.
- edblarney 10y ago
  Don't devalue yourself. What you perceive as 'cosmetic' might be some really minor thing ... but it may be absolutely critical to your customers operational needs. Remember if you have zero IT ability than the smallest process change can be a huge pain. Example: Customer Service may be a great chance for customers to give a heads up about things that are broken or needed features. CS Reps might hear about it all the time. But they have no way to log that information, or for it to be refined. Product leaders therefore are screwed: there most important feedback is lost. With a small change to CSR, staffers can make note of things, put priorities, now if there is a 'blow up' in a release, product can know about it right away. Very small change can mean big impact.

vlozko 10y ago

I largely agree with you. The challenges with this largely fall on the business side. I've once worked at a place where a customer agreement was structured in such a way that tied up our development and QA resources for resolving issues for them that weren't due to a fault on our product. For a small company of ~10 developers, we spend an awful amount of time tying up resources on tracking down issues that ended up being bugs in their own software; they just happen to discover them while using our product. And we really didn't get all that much money from them, either. It's not uncommon for a small startup to tie themselves up with a poor customer agreement for the sake of name recognition or misplaced hope in the agreement opening doors down the road.

metaphorm 10y ago

CDD is when a customer is convinced to buy very expensive software that amounts to nothing more than a cosmetic upgrade to their existing broken process.

edblarney 10y ago
Don't devalue yourself. What you perceive as 'cosmetic' might be some really minor thing ... but it may be absolutely critical to your customers operational needs. Remember if you have zero IT ability than the smallest process change can be a huge pain. Example: Customer Service may be a great chance for customers to give a heads up about things that are broken or needed features. CS Reps might hear about it all the time. But they have no way to log that information, or for it to be refined. Product leaders therefore are screwed: there most important feedback is lost. With a small change to CSR, staffers can make note of things, put priorities, now if there is a 'blow up' in a release, product can know about it right away. Very small change can mean big impact.