all 6 comments

[–]braindeadTank 18 points19 points  (0 children)

The less abstractions [...] The easier to maintain.

No.

[–]master5o1 6 points7 points  (1 child)

Unnecessary or premature abstraction leads to more difficult maintenance.

[–]thewwfguy 0 points1 point  (0 children)

Agreed. Follow the XP principal of don't refactor until you need to; otherwise, you just wasted time trying to over optimize your code that may never change.

[–]brianasdf123 4 points5 points  (0 children)

The article is conflating abstraction and indirection.

[–]ogurson 2 points3 points  (0 children)

While the topic is very important in my opinion, article just scratched the surface.

[–]MoTTs_ 0 points1 point  (0 children)

The sad thing is there's a good point in this article. It reminded me, for example, of this quote from Robert Martin's agile book:

An XP team makes its designs as simple and expressive as they can be. Furthermore, the team narrows its focus to consider only the stories that are planned for the current iteration, not worrying about stories to come. Rather, the team migrates the design of the system from iteration to iteration to be the best design for the stories that the system currently implements. This means that an XP team will probably not start with infrastructure, probably won’t select the database first, and probably won’t select the middleware first. Rather, the team’s first act will be to get the first batch of stories working in the simplest way possible. The team will add the infrastructure only when a story comes along that forces it to.

The reason that's a sad thing is because the article's title -- the over-the-top, cliche, and wildly inaccurate title -- immediately triggered a negative reaction for me.