3 ms·
We barely crossed paths, but in the couple of interactions we had he changed my engineering for the better. In particular, he demanded that all features have m
by tsmarsh 9y ago
We barely crossed paths, but in the couple of interactions we had he changed my engineering for the better.
In particular, he demanded that all features have measurable success criteria and if they didn't happen he pulled the feature from the code base.
Simple and elegant way of keeping your code base small and focused. The real miracle there was he got the customer to agree and held them to it. I still don't know how he did that.
- hnarn 9y agoHow are you supposed to test it if there's no success criteria? And by extension, how are you going to write good software without tests?
- zentiggr 9y agoNever worked with professional-in-other-field types? Nothing is ever 100% specified, either initially or at any moment going forward. Best you can do is pick highlights from the stream of desires and try to code to those, and expect to get it 'wrong' 100% of the time until its suddenly OK for any one of a hundred reasons. Or have someone suddenly cut the contract off and never finish. Good software without tests: not easy but can, rarely, happen anyway.
- tsmarsh 9y agoSorry, I wasn't clear. It wasn't if the software functioned the way that we wanted (is the business logic correct), so much as did it have the effect on the business that we wanted. The criteria would have been something a long the lines of: "By adding this ad banner to this page template we will increase revenue by 5% per page view", or "By adding this widget to the on boarding page we will reduce drop out by 50%". If your feature didn't have the business impact it was supposed to, it was pulled. Maybe the widget actually increases drop out? Maybe increasing ads reduced page views? But it prioritized being to answer those kinds of questions. Very neat.