Slashdot Mirror

← Back to Stories (view on slashdot.org)

Evolving the Development Process?

Posted by Cliff on from the learning-new-ways-to-work dept.

cabbage queries: "I just joined a medium sized firm with a development department of approx. 250 people. They primary product is a client-server based solution delivering realtime market data to the desktop in large financial institutions. They currently use SCO Unix for the servers, but a move to Red Hat Linux is definately in the cards. But this isn't the only change thats happening: they are also considering integrating their data with the client's enterprise delivery systems, and proprietary applcations. Currently they use a 'pragmatic' version of the Unified Process utilizing UML. The process is well organized and reasonably well documents and seems to serve well as a development process. However, it doesnt address the requirements of systems integration where the requirements are ill-defined, require extensive R&D, may only be tested on site, and may not be complete until the client determines that the solution does what they thought they wanted. Do any slashdotters have any suggestion as to how to move from a well organized application development process to one that addresses systems integration without destroying the application development process. We really don't want to set up a seperate department if at all possible."

8 of 19 comments (clear)

  1. Abstract to invarients by renehollan · · Score: 2
    That is, try to model the interfaces to the implementations that you don't yet have a handle on.

    This won't be perfect, but it should fit within the amount of churn that youyr development model already accomodates.

    --
    You could've hired me.
  2. absurd, isn't it? by GCP · · Score: 2

    And he may not actually be anti-semitic, just doing the only thing his tiny mind can think of to get attention.

    --
    "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
  3. Design Reviews by Phaid · · Score: 4, Insightful

    However, it doesnt address the requirements of systems integration where the requirements are ill-defined, require extensive R&D, may only be tested on site, and may not be complete until the client determines that the solution does what they thought they wanted.

    Unfortunately, if you can't eliminate that last bit (until the client determines that the solution does what they thought they wanted) then, to put it nicely, you're pretty much going to be stuck in an endless "stepwise refinement" process. Making changes to a mostly-complete application can be a nightmare; the key thing here is to do all of the "stepwise refinement" in the design phase, before you start doing any coding.

    This is just Software Engineering 101. If you don't want projects to turn into a death march, you have to get firm requirements. Then you design your solution, and have design reviews with the client until both of you are satisfied that what you are designing is what they will want. Do not start coding anything until you've reached that point. Prototyping is fine, but starting to build a project before the client has signed off on the final design is a great way to shoot yourself in the foot.

    The "extensive R&D" part and the "testing on site" part are just more work, that's life. But you have to get a commitment from clients that what you are building for them is what they need, and that once they've signed off on the design, change orders are going to be very expensive. If you know what you're building ahead of time, and the client knows what they're getting, you are going to have a lot fewer problems.

    1. Re:Design Reviews by Dancin_Santa · · Score: 3, Insightful

      If, as it sounds to me, they've already got a solution developed and are merely updating and bug-fixing it as their main development effort, wouldn't it be saner to keep those existing developers at home and simply create the dreaded "new department"?

      It sounds as if they are thinking of moving into the area of on-site support and integration while keeping the development effort going. It makes sense (to me) to have specialists in the code, and specialists in integration. Both departments can play off one another and improve the quality of the software as a byproduct of their interaction.

      Also, having people in the field who are solely focused on solving immediate customer problems will gain quite a bit of insight into future products that might be profitable for the company to develop.

      JMHO,

      Dancin Santa

    2. Re:Design Reviews by MrBlack · · Score: 2

      Interesting. I wish I had mod points to mod you up for this one. So far all the other comments in the thread have been pretty "safe" - make sure you get all the requirements up-front (ignoring the reality that some customers don't know exactly what they want, some can't articulate it, and some systems that you may have to interact with are so old and arcane that the only way you'll really know something doesn't work is 3 weeks after you've integrated with it and something goes wrong), abstract your interfaces, read the mythical man-month. You on the other hand are advocating somthing much more interesting. Good work Dancin Santa!

    3. Re:Design Reviews by Dancin_Santa · · Score: 2, Insightful

      I really don't see what I'm advocating as anything groundbreaking at all. It sounds like cabbage's company is trying to shoehorn a consulting business into a traditional product-based business without breaking either business. I just don't see that happening without a lot of pain.

      I'm sure they've already got a few developers who trek out to customer sites to implement their current product. Why don't they simply build a team around these engineers and label them the "Product Integration" team. It would free them up from having to develop the product and let them focus on customer issues. Not only would this allow for quite a bit of specialization within the company, it would allow both divisions to grow independently of each other making it possible for the company to branch out into other profitable markets.

      The benefits of having the separate teams is pretty clear. Better customer service, more forward-looking ideas, and more expertise among the engineers of each division are only a few of the ones that pop into my head straight away.

      I'm sure there are a few engineers who are already interested in doing something besides crunching code all day long. Grab 10 or so of them and make them the Integration team. As these guys get better, the quality of their work and their implementation schedules will improve immensely.

      IMHO, of course.

      Dancin Santa

  4. Mythical Man Month by djn · · Score: 2, Informative

    If you haven't already, try reading The Mythical Man Month by Frederick P. Brooks, Jr.

    It is (as far as I know) the book on project management. It's over 20 years old and it's certainly stood the test of time. It's written in a nice, readable form... and it's an interesting read to boot.

    -Dan
    www.unixpunx.org - unix, punks, technology

  5. XP by egeorge · · Score: 4, Insightful
    XP (eXtreme Programming) has some good insights for this kind of situation.

    Instead of waiting for large releases to do integration testing or customer approval, you can "tighten the loop" and do faster iterations with the process you already have.

    Once you have your use cases and UML and everything, then pick a couple of basic features and build them fast and release them (Don't forget to write automated tests). That way you get customer feedback and integration testing practice quickly and can fix things bit by bit instead of having to gut your system to add a trivial feature later in the process.

    I have found the XP principles of rapid iteration and continuous integration to be life savers regardless of what other methodologies are being used.