|
|
|
|
|
by rolfvandekrol
3469 days ago
|
|
Although the points in this article appeal to me, as a software developer who would gladly take all the time in the world to work on a problem for as long as I want, the world simply does not work that way. The words 'money' and 'economy' are not present in the text. The writer does not seem to realise how his/her salary is paid. A problem does not exist in isolation. It exists because after the problem is solved someone is going to (or expects to) make more money than before the problem was solved. The solution to the problem is only viable if the cost of solving the problem does not exceed the economic benefit of the solution. This longflow methodology does not provide any way to manage those costs. |
|
Well, the world is not a software developer, so hard to argue what would be if it was. Or your grammar was off.
> [being] a software developer who would gladly take all the time in the world to work on a problem for as long as I want, [...]
"Taking all the time" to "work on a problem" is so boring. I would get fed up with the problem after a quarter. "The problem" is actually a fractal of things that need to be done before a perfect solution arises, and I've seen many such fractals of work.
Fortunately I'm a half-programmer, half-sysadmin, what results in me writing tools for fellow sysadmins. Such tools are very, very rarely larger than a dozen KLOC, so I tend to jump between problems and runtimes and languages quite often compared to regular programmers. It's so refreshing to write Perl after an Erlang application, to update shell script after writing a C library, or to debug Python module after designing a network protocol, or to analyze firewall behaviour after writing a Ruby plugin for data router daemon.
Time constraints (realistic ones) give some framework to work with. They are a good thing, if not abused. But the same stands for any other type of constraints (memory, disk space, response time, specific runtimes that are already present on target system, system's autonomousness, application's transparency and monitoring, etc.).