Feedback on Ed Roman's J2EE Project Management article

Discussions

TSS feedback: Feedback on Ed Roman's J2EE Project Management article

  1. Ed,

    I found it a practical and useful article, but feel I should point a few things, which may not be obvious to readers, and tend to cause problems.

    You suggest to "Design your complete object model" and after that, to "Implement a single vertical slice". By attempting to get the entire design right FIRST, you are exposing yourself to architectural risk; and you will probably have a lot of design re-work after coding each slice.

    The early iterations of a project should focus on covering the breadth of the problem, and zoom down into the depth (complexity) at the most critical points. Once a stable architectural baseline has been achieved, the rest of the system is completed incrementally (in vertical slices).

    This means, that while it is a good idea to implement a single vertical slice, this should only be done after you have a stable architecture. And when you select a slice to implement, you should also detail the requirements and design for that slice before you code it. Therefore, you will not complete your design before coding begins, but the design (and requirements) will also evolve stepwise, like the code.

    The point at which you refer to RUP, you mention a "skeleton". This is the idea behind building iteratively and incrementally, but I fear some people might confuse this "skeleton" with the architectural baseline defined in RUP.

    They are not the same thing - an architectural baseline cannot be the result of a single vertical slice of the system - it needs to provide coverage (problem breadth) and criticality (detail at the most critical points). A "skeleton" would not provide either of these very necessary characteristics.

    Thanks

    DJ de Villiers
    Rational Software
  2. DJ,

    I also found article very useful and in many aspects match my line of thought to do a result oriented Software development.

    >>This means, that while it is a good idea to implement a single vertical
    >>slice, this should only be done after you have a stable architecture.
    "Implement a single vertical slice". To my knowledge means implementing functionality using the proposed software and system architecture. This way you come to know the architectural risk. Also I will select functionality within the whole scope of project with which I can test the limits of architecture under said condition. This vertical slice implementation is like a mini project that activates and involves all the aspects of the project. In terms of Ed I will involve both generalists and specialists to do this vertical slice.

    I may have to disagree with you that early iterations of the project should focus on covering the breadth of the problem. This way I will be too late to gain confidence of my Investors and stakeholders. Business peoples get confidence by looking at a working functionality under recommended environment. I personally follow agile process methodology and believe that the breadth of the problem can be achieved incrementally in parts.

    >>They are not the same thing - an architectural baseline cannot be the result
    >>of a single vertical slice of the system
    If a project involves a architectural complexity say it involves integrating multiple databases, Integrating with Legacy, lot of workflow, etc then I recommended to slice the Project into sub projects and let each sub project take care of its own architecture.

    Thanks and Regards,

    Uday Bhosle
    B3Web