My code for @ReliScore is slowly falling for Greenspun's tenth trap, "Any sufficiently complicated program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp" as we implement automated eligibilty criteria for candidates
Customers want to make candidates appear for different tests based on various criteria (branch, percentage, score on first round test, etc). And of course, I don't want to hardcode that. So I've ended up with a mini expression language.
And now there's classic score creep.
And now there's classic score creep.
Never imagined my eligibility specification language would end up with variable declarations and scopes
It has all arithmetic and Boolean operations and conditional branching. No loops yet
Looking forward to the day when a customer requirement forces me to implement recursion
It has all arithmetic and Boolean operations and conditional branching. No loops yet
Looking forward to the day when a customer requirement forces me to implement recursion
It is funny how "Jo sochta hai, woh hota nahiN hai. Jo hota hai, woh sochne lagta hai" applies to software development when you're listening to customers
All this sophisticated machinery is required because customers ask for what they think of as "simple requirements"
but...
All this sophisticated machinery is required because customers ask for what they think of as "simple requirements"
but...
The converse is also true. There are features I'd envisioned on day 1 (ten years ago) that I still haven't implemented as no customer has really needed them.
As @dnene once told me, one of the most important principles of software design is YAGNI: martinfowler.com/bliki/Yagni.ht…
As @dnene once told me, one of the most important principles of software design is YAGNI: martinfowler.com/bliki/Yagni.ht…
Notice how, in the context of customers, I carefully used the word "needed" instead of "wanted" or "asked for".
This is something I've learnt over the years. During initial pitches, customers ask for all sorts of features which they don't need (and will never use). Resist.
This is something I've learnt over the years. During initial pitches, customers ask for all sorts of features which they don't need (and will never use). Resist.
What customers ask for before they sign up (i.e. when they're thinking about the problem theoretically) is often quite different from what they want when actually using the software (when there is skin in the game)
So YAGNI applies to the customers too
So YAGNI applies to the customers too
This also ties in to the most common advice I give first-time startup founders: Don't implement any of the sophisticated features you're thinking until you've talked to 30 potential customers.
In fact, don't write any code until you have customers.
In fact, don't write any code until you have customers.
In fact, the first 6 months of many startups don't need any software implementation other than Excel and Whatsapp.
Far too many founders waste a lot of time and money building sophisticated software that YAGNI.
Far too many founders waste a lot of time and money building sophisticated software that YAGNI.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
