3 ms·
Formalizing the process is a noble goal, but there will always be clients that want your formalized process with "just a few tweaks". I think we should endeavo
by blunte 9y ago
Formalizing the process is a noble goal, but there will always be clients that want your formalized process with "just a few tweaks".
I think we should endeavor to formalize as much as is reasonably possible, pushing the bulk of the developer work to dealing with the special cases. But even that will eventually result in a small formal core surrounded by layers and chunks of customizations.
- catnaroek 9y ago> Formalizing the process is a noble goal, but there will always be clients that want your formalized process with "just a few tweaks". The client owns the process - it's their business after all - so they can define it however they wish. I'm not arguing for canned software. I'm arguing for a programming language in which business processes can be defined directly. (I'm aware of the existence of BPMN, ARIS, and other business process modeling tools, but those fall short of being actual programming languages.)
- blunte 9y agoI'm for whatever tools lead to better outcomes (more complete solutions for less cost). From my experience, however, non-technical decision makers often start from the assumption that the things they want are easy. As such, they tend to be reluctant to invest in new technologies or approaches. In fact, the most common first approach when they become convinced that what they want is actually "big" is to attempt to offshore. In other words, they naively assume that the solution to complexity is more (cheaper) bodies. So even if a great tool comes along that allows us to meet needs more effectively, it's not guaranteed to be accepted.