Thinking Iterative, but doing Waterfall development

Some companies think they’re applying iterative and incremental development, but in practice are doing waterfall development. Here are some tips described in Applying UML and Patterns, by Craig Larman, which can help you discover if your company doesn’t understand the Unified Process and iterative development (these tips can clarify all stakeholders misunderstanding about the difference of the two approaches):

  1. You think that inception = requirements, elaboration = design, and construction = implementation (that is, superimposing a waterfall lifecycle onto the UP).
  2. You think that the purpose of elaboration is to fully and carefully define models, which are translated into code during construction.
  3. You try to define most of the requirements before starting design or implementation.
  4. You try to define most of the design before starting implementation; you try to fully define and commit to an architecture before iterative programming and testing.
  5. A “long time” is spent doing requirements or design work before programming starts.
  6. You believe that a suitable iteration length is four months long, rather than four weeks long (excluding projects with hundreds of developers).
  7. You think UML diagramming and design activities are a time to fully and accurately define designs and models in great detail, and of programming as a simple mechanical translation of these into code.
  8. You think that adopting the UP means to do many of the possible activities and create many documents, and thinks of or experiences the UP as a formal, fussy process with many steps to be followed.
  9. You try to plan a project in detail from start to finish; you try to speculatively predict all the iterations, and what should happen in each one.
  10. You want believable plans and estimates for projects before the elaboration phase is finished.
  11. Are you involved in such a situation at your company?

Do you need closures in Java?

TheServerSide has raised a question about whether closures proposals to be implemented in the Java language are really necessary. In my opinion, I think the Java language must be as it is, because:

  • Generics syntax introduced in Java 1.5 are very difficult to understand and parse when code is read; mixing it with closures will keep the code a little messy;
  • People would prefer to do things in the way they are used to, instead of learning a new construct in the language to implement their tasks (it’s better to focus on code maintenance and readability, after all, code is more read than written);
  • Anonymous-inner classes are far less readable than inner classes, imagine when closures appear in such a code;

So, I think it’s better to maintain the language with the abstractions it already offers and focus on other improvements, like reifiable generics, that is, making generic type information available at runtime. And you? Will you think useful closures on the Java language?

Web 2.0 ‘neglecting good design’

Here is an interesting interview with the usability guru Jakob Nielsen which he says web firms are so emphasized in the hype of Web 2.0 as the “latest fashion” and at the same time the basic principles of webpages usability are always being forgotten. He claims about companies have to focus first in making good practices available like “making a site easy to use, good search tools, the use of text free of jargon, usability testing and a consideration of design even before the first line of code is written”. Also, Mr Jakob Nielsen says, as a interesting note, “The idea of community, user generated content and more dynamic web pages are not inherently bad in the same way, they should be secondary to the primary things sites should get right.”

Google Guice, dependence Inversion in the Java way

Check out this great video about the new Java based inversion control framework from Google. The guys Kevin Bourillion and Bob Lee explains the concept behind dependency inversion principle (dip) and the core features inside Google Guice, called ‘juice’. The framework embraces and uses annotations instead of string identifiers (heavily used in Spring) to inject dependencies into the code. The most interesting feature is that Guice injects constructors, fields and methods (any methods with any number of arguments, not just setters) . You can also integrate Spring with Guice. Enjoy!