5 ms·

I don't get this article, the author identifies the issue immediately: > in the process, we often lose sight of the business problems being solved And then go

I don't get this article, the author identifies the issue immediately: > in the process, we often lose sight of the business problems being solved And then goes on tangents as to why that is happening finally arriving on what tantamounts to "developers don't like to use visual UI tools". The original cause identified is right, people lose sight of business goals, but why? Because they have poor project management and they are in the trenches all day long. They want to do right by the code base, so they abstract things which don't need to be abstracted. The failure here is one of trade off analysis and again losing sight of what is important, shipping a usable product which meets business goals.

emodendroket 9y ago
I mean overall I feel like this article is going in an unconvincing circle because it is trying to solve a problem that doesn't have a solution. "We want software to be faster to market than ever, have higher availability than ever, have more complex feature sets than ever, but also have higher quality and accommodate constantly-changing requirements. Also it needs to be secured to an extent that would have not necessarily been necessary pre-Internet. Oh and we'd like to keep down wages as much as possible as well."
jetheredge 9y ago
Author here... I agree that developers often lose sight of the business problem being solved, but I think just stopping there is an over-simplification. It is very possible to build an application that serves the business problem adequately, but is grotesquely over-engineered or solves the problem in a ridiculous way. The world is built on software like that. My point was that we are introducing a lot of needless complexity to systems, all in the name of following trends or chasing the new shiny. And we are hurting ourselves by doing it.
Bartweiss 9y ago
> they abstract things which don't need to be abstracted I'm trying to remember the last time I encountered a code base more than a year old and thought "the problem here is too much attempt at abstraction and elegance". Broadly, my experience is approximately the opposite: over-abstraction happens to meet amorphous and unpredictable use cases, while any longstanding code base is full of un-designed hacks that arise from a constant short-term approach.

emodendroket 9y ago

I mean overall I feel like this article is going in an unconvincing circle because it is trying to solve a problem that doesn't have a solution. "We want software to be faster to market than ever, have higher availability than ever, have more complex feature sets than ever, but also have higher quality and accommodate constantly-changing requirements. Also it needs to be secured to an extent that would have not necessarily been necessary pre-Internet. Oh and we'd like to keep down wages as much as possible as well."

jetheredge 9y ago

Author here... I agree that developers often lose sight of the business problem being solved, but I think just stopping there is an over-simplification. It is very possible to build an application that serves the business problem adequately, but is grotesquely over-engineered or solves the problem in a ridiculous way. The world is built on software like that. My point was that we are introducing a lot of needless complexity to systems, all in the name of following trends or chasing the new shiny. And we are hurting ourselves by doing it.

Bartweiss 9y ago

> they abstract things which don't need to be abstracted I'm trying to remember the last time I encountered a code base more than a year old and thought "the problem here is too much attempt at abstraction and elegance". Broadly, my experience is approximately the opposite: over-abstraction happens to meet amorphous and unpredictable use cases, while any longstanding code base is full of un-designed hacks that arise from a constant short-term approach.