SoylentNews is people
SoylentNews
from the a-language-is-not-just-a-bunch-of-words dept.
Up on ACM queue is an article by Bertrand Meyer on the difficulties of feature-based development, and the implications for Agile development methods.
Everyone wants simple solutions. But it is not enough for a solution to be simple; it must also work. The idea that you can specify and build a system by discovering user stories as you go and implementing them one after the other, with some refactoring here and there to clean up the design, is clear and simple, but only in the sense of the famous H. L. Mencken quote ("clear, simple and wrong").
Meyer is probably best known to programmers as the author of the programming language Eiffel and his writings on object oriented architectures. He has also written on agile development methods in detail — the article is based on a chapter from his book.
(Score: 3, Interesting) by Cheburator2 on Sunday February 22 2015, @11:13PM
I never encountered a project where all required features could be enumerated beforehand. When users get to test a beta version, they always begin to have those strange desires that were not discussed at the beginning of the project. So, Meyer could talk all he wants about multiplicative complexity, that doesn't change the fact that you simply don't know how your project would change in time. All you can do is to make sure that changes and refactorings would require minimum work: write your tests (not useless unit tests for each method, but tests for complex real-world scenarios), use languages and IDEs that could automate refactoring (no dynamic typing and no macros-based languages like C++) and make sure that your code generally looks good (minimum copy-paste, no spaghetti code, good abstractions and so on).
(Score: 1) by angelosphere on Monday February 23 2015, @11:42AM
Actually IDE based automatic refactoring was invented with dynamic typed languages / IDEs like SmallTalk and Lisp.
The first paper where the term refactoring was coined was written by a scandinavian and based on Lisp, somewhere around 1995.
I personally prefer statical typed languages, too, but slowly I get a hang on Groovy.
(Score: 1) by Cheburator2 on Monday February 23 2015, @12:30PM
I also love dynamic typed languages, but there is a limit to what could be done with them in regards to automatic refactoring. You have to have a static type information in order to find specific code patterns or navigate type hierarchy. For example, my project has dozens of classes which has methods with generic names like getName or getValue which in turn are used in hundreds places. Even a simple refactoring of adding a new parameter to such method in a particular class would be a nightmare in dynamic typed project, because you'd have to traverse through thousand of usages and inevitable there would be errors not catched by compiler and not covered by tests. It takes less than an hour for me with automated static typed refactoring and there are usually no errors afterwards.
TL/DR: It's fun to use dynamic typed languages for small projects, but they really limit agility for large projects.