23 karma · joined September 2, 2013
Edit: corrected autocorrect
If you simply say follow the ISO standard you’re essentially making it easy for yourself and hard for the users. Sprinkle that with a drop down day picker as in the example, and you’re really in control of what the input will be. Not much chance of faulty input, right?
However, the ISO will not be relatable for many people and the drop down is a UI nightmare.
The user will be spending much more time with the form than devs (runtime), so this of thinking should definitely be avoided (during programming time).
I really dislike that tendency in design and behavior and find it counterproductive.
Of course, the room wasn’t empty and void other sounds, which may have helped me build a general sense of direction and thereby helped me.
Edit: missing word
I think that’s a healthy way of doing it, but sadly many almost have to be pushed to do it, even with bigger things.
It’s sad. Just recently had an experience like this with developers I manage. I do loathe the brogrammer culture more than anything...
I’m actually proud of the parts of agile we work with, which primarily enables us to react changing needs and priorities quickly (unlike heavy waterfall).
After 22+ years in the industry I’ve come to realize that any new concept or concept that gets traction (CQRS, Event storming, AI) will produce a religious following. It’s kinda sad, because causes as lot of noise and friction.
The name escapes me, but it’s about the fact that once, even though laws were passed, it required personnel to enforce it, so there was a sort of a natural equilibrium between government and citizens. But now that we have all this technology, law enforcement can enforce even the pettiest of laws...?
I remember when i realized that TDD shouldn't have such weight in our development as it had gotten (when it was high on the hype curve).
It was when we starting using a messaging infrastructure that made everything much more reliable and robust, and trough which we could start trusting the infrastructure much more (not 100% though, of course).
It made me realize that the reason why we did this excessively large amount of tests (1800+) was because the fragile nature of a request/response-based system and we therefore "had to make sure everything worked".
What I'm trying to get at here is thar TDD assumed the role of a large safety net to a problem we should have addressed in a different manner. After introducing the messaging, we could replay messages that had failed. After this huge turning point tests were only used for what they should have only been used for - ensuring predictable change in core functionality.
(our code also became easier to understand and more modular, but that's for another time...)