3 ms·

I would always reach for scripting every time. Getting a working implementation and experiencing real world data + problems as soon as possible is always best i

I would always reach for scripting every time. Getting a working implementation and experiencing real world data + problems as soon as possible is always best if you are taking an iterative approach. Unless there are some serious domain experts on hand, I feel mapping the problem space is the most valuable approach - and one of the best ways to do this is to attempt a fast and basic solution. The alternative is a big design up front with minimal experience in the subjext domain. It feels like the inverse of "I'm going to scale my foot up your ass"[1] - how useful are your reliability and metrics if your service is never used / becomes irrelevant / newspaper business dies / company folds / huge paradigm shift in tech. I feel the dirty hack is a valuable step in the process, and its not possible to jump to the end without mapping the route first. [1] http://widgetsandshit.com/teddziuba/2008/04/im-going-to-scale-my-foot-up-y.html http://widgetsandshit.com/teddziuba/2008/04/im-going-to-scal...

lumost 7y ago
From experience most of the time when an engineer can't write down a design for what they'll be delivering over the next 6-12 weeks, they won't be able to deliver the desired outcome in shorter iteration cycles either.
- pmontra 7y ago
  6 to 12 weeks? I used to have 6 to 12 months and a team that delivered software and designs. Change of job, my customers ask me to deliver features in the next 6 or 12 days now, and I work less than 50% of the time for any them. Design is made on paper or only in my mind, documented in markdown (when I have plenty of time) or comments on YouTrack or kanbanize (customer choice), software written in Elixir, Python, Ruby, some JS. Sometimes I complain that they want to rush sw into production without letting it settle down in staging, then lose time fixing unexpected cases.
TheOtherHobbes 7y ago
It depends on the domain. CRUD should be by the numbers, unless you're working at planetary scale. But some domains are very poorly understood. You won't get far by trying to iterate - because you don't even know what the problem is, never mind how to solve it, and your dirty hack is going to introduce naive assumptions that turn out to be spectacularly wrong.
- smcameron 7y ago
  Though as John Gall famously said, "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system."
- greggyb 7y ago
  Coming from a perspective of the IT consulting world, CRUD apps are rarely that simple. The core is always the same, sure - you're basically wrapping read and write transactions to a storage subsystem in a pretty veneer. The complexity is never in the CRUD actions themselves. But transforming the things that have been R-ed so we can U them or identifying the full population of things to be D-ed is often non-trivial and deeply tied into understanding of the business domain and process at hand. Often (analytics and reporting lenses on here), the complexity is in modeling the data appropriately and the logic of transformation. The work of presenting this stuff to a user is basically trivial arithmetic.

lumost 7y ago

From experience most of the time when an engineer can't write down a design for what they'll be delivering over the next 6-12 weeks, they won't be able to deliver the desired outcome in shorter iteration cycles either.

pmontra 7y ago
6 to 12 weeks? I used to have 6 to 12 months and a team that delivered software and designs. Change of job, my customers ask me to deliver features in the next 6 or 12 days now, and I work less than 50% of the time for any them. Design is made on paper or only in my mind, documented in markdown (when I have plenty of time) or comments on YouTrack or kanbanize (customer choice), software written in Elixir, Python, Ruby, some JS. Sometimes I complain that they want to rush sw into production without letting it settle down in staging, then lose time fixing unexpected cases.

TheOtherHobbes 7y ago

It depends on the domain. CRUD should be by the numbers, unless you're working at planetary scale. But some domains are very poorly understood. You won't get far by trying to iterate - because you don't even know what the problem is, never mind how to solve it, and your dirty hack is going to introduce naive assumptions that turn out to be spectacularly wrong.

smcameron 7y ago
Though as John Gall famously said, "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system."
greggyb 7y ago
Coming from a perspective of the IT consulting world, CRUD apps are rarely that simple. The core is always the same, sure - you're basically wrapping read and write transactions to a storage subsystem in a pretty veneer. The complexity is never in the CRUD actions themselves. But transforming the things that have been R-ed so we can U them or identifying the full population of things to be D-ed is often non-trivial and deeply tied into understanding of the business domain and process at hand. Often (analytics and reporting lenses on here), the complexity is in modeling the data appropriately and the logic of transformation. The work of presenting this stuff to a user is basically trivial arithmetic.