Discussions

News: Vincent Frisina on Large-scale Development Environments

  1. According to Vincent Frisina, principal consultant for U-plus Consultant, the biggest challenge in a large-scale development environment is communication. With approximately fifty developers plus management, QA and support currently working together to replace a client's existing enterprise critical application with a new overall system, as well as integrating with other applications within the enterprise that are being replaced, Frisina experiences that challenge firsthand. In this tech talk, Frisina discusses the obstacles the team faces and advances they've made in this project, including: -Harvesting common frameworks to enable reuse - Company policies around design patterns - How AOP helped to isolate the code from the rest of the team and the performance tradeoffs that resulted - How IOC was used in the project - Incorporating Agile development techniques in a large non-Agile established company - Automated testing in a large-scale environment Watch Vincent Frisina on Large-scale Development Environments.

    Threaded Messages (12)

  2. Umm... It's ePlus. http://www.eplus.com
  3. He did not say WHY an entire system is being replaced. Replacing an entire system seems to happen vary rarely - you only replace when something is broken. That's why there's still so much mission-critical enterprise applications written in C++. The current 'best practice' of existing systems seems to be to modularize, expose as service, and develop new components in Java in a SOA. So I'm very interested to hear what went so wrong that they decided to replace rather than reuse. PJ Murray, CodeFutures Software Data Access Objects and Service Data Objects
  4. Why we did it[ Go to top ]

    He did not say WHY an entire system is being replaced.
    The decision to replace the old systems was economic. First, new features and major changes to existing features would be necessary for the services being offered to remain competitive with other providers in their industry. Second, there was a need to streamline several radically different systems. Third, the skills necessary to maintain any one of the old systems were rare, and it was nearly impossible to find someone with the skills necessary to work in all of them. The best estimate of the ongoing maintenance costs, new development costs, and the size of the market window showed that it made sense over the long term to build a replacement system. As we approach the release to production, it looks like those estimates were correct. This is not something you undertake lightly or because of you want newer, shinier code. Sometime the decisions made as the systems evolved over the course of thirty years put the system in a place where radical change is necessary and very difficult. In this case, whether we called it a new system or a new version of the old ones, it would have been a complete overhaul, and I believe it would have been more expensive and slowed the team down to rewrite the systems from the inside out rather than starting with a blank slate. Vince Frisina http://www.eplusconsulting.com http://www.jroller.com/page/vfrisina
  5. Re: Why we did it[ Go to top ]

    Thanks for getting back! I enjoyed your presentation and think you were brave to undertake a project like that. I also agree with the posting above about reading-between-the-lines.
    Third, the skills necessary to maintain any one of the old systems were rare, and it was nearly impossible to find someone with the skills necessary to work in all of them.
    I suspect this might have been the primary reason - and is probably the primary reason in most cases. It is especially true for older systems developed in anything other than C++ (COBOL for example). The first reason - new features - is usually not good enough a reason to get rid of old stuff. Neither is the second reason - streamlining - is also not usually good enough a reason. Of course, in this case, the existing system might not have allowed new features and the diversity of systems might have been unmaintainable. PJ Murray, CodeFutures Software Data Access Objects and Service Data Objects
  6. Re: Why we did it[ Go to top ]

    Thanks for getting back! I enjoyed your presentation and think you were brave to undertake a project like that.

    I also agree with the posting above about reading-between-the-lines.


    Third, the skills necessary to maintain any one of the old systems were rare, and it was nearly impossible to find someone with the skills necessary to work in all of them.


    I suspect this might have been the primary reason - and is probably the primary reason in most cases. It is especially true for older systems developed in anything other than C++ (COBOL for example).

    The first reason - new features - is usually not good enough a reason to get rid of old stuff. Neither is the second reason - streamlining - is also not usually good enough a reason. Of course, in this case, the existing system might not have allowed new features and the diversity of systems might have been unmaintainable.


    PJ Murray, CodeFutures Software
    Data Access Objects and Service Data Objects
    While a number of factors went into the decision, I believe the primary reason was the difficulty of finding people with the right skill set for the previous system. The first two reasons--new features and streamlining--were what made the other so serious. Significant new work was going to be necessary, and meeting the market window would require bringing in many more people no matter what. Given that there have been times we could not find enough Java programmers to fill the open slots, I am certain that we would have had zero chance of finding enough people to do what was necessary in the old system within the timeframe we had to work with. Vince Frisina http://www.eplusconsulting.com http://www.jroller.com/page/vfrisina
  7. persistence decision[ Go to top ]

    DISCLAIMER: I hope to have a job some day that will include work on projects on the scale of what you have described in your talk. These questions are for the sake of furthering knowledge only!! :-)) Is it not important to have the persistence nailed before anything else is done? I guess my questions are: What was the reasoning behind using Entity beans in the first place ? Why are you now looking at alternatives? Is it not necessary to have the above discussion before the system is designed?
  8. Re: persistence decision[ Go to top ]

    What was the reasoning behind using Entity beans in the first place?
    Because they were hyped for years by Sun, Java trade magazines, TSS and any Java centic site on the internet?
    Why are you now looking at alternatives?
    Because Entity beans are a complete failure?
  9. Re: persistence decision[ Go to top ]

    Is it not important to have the persistence nailed before anything else is done?
    Certainly, and we did have that nailed down, or at least we thought we did. As we developed the system and new requirements were defined, our use of persistent data objects evolved to meet them. Eventually, we found that we were taking on all the overhead of entity beans without any of the benefits. That led to to investigate other means of handling persistence. We have since settled on Hibernate, which meets our current needs wonderfully. It is worth noting that I was at TSSJS to present this project as a case study in agile methods on large-scale projects. In this case, we had an initial vision of the system, but it was known that the requirements would evolve as different business units refine their own understanding of what they need. The development team can "nail down" whatever we want, but it would have as much meaning as declaring the sky would henceforth be green. Instead, we had to adapt to the changing needs of the business units. Understand that they were not just being difficult. They were working just as furiously as we were to understand what the market demanded, what the users needed, and how they could improve their processes using the new system. The whole premise of my presentation was that while most discussions of agile methods focus on small teams, large projects need agility even more because so many stakeholders will be involved and their communal understanding of the system is bound to evolve over time. In this case, we did not change the persistence implementation because it seemed like fun. We found that using entity beans put us in danger of not meeting our requirements. It may have been possible to make entity beans work, but the lower risk and lower cost choice given our architecture was to switch to Hibernate.
    I guess my questions are:
    What was the reasoning behind using Entity beans in the first place ?

    Why are you now looking at alternatives?

    Is it not necessary to have the above discussion before the system is designed?
    We used entity beans because they were considered the lowest risk choice at the time. Vince Frisina http://www.eplusconsulting.com http://www.jroller.com/page/vfrisina
  10. thanks!![ Go to top ]

    thanks for all the replies!! another reason why I asked the question was: I have just finished reworking the data layer of a small project (10 to 12 screens along with a couple of web services) and moved it from entity beans to iBatis. I was not part of the team that decided to use EB (just got stuck with prod support work) and had to convince management to change it. Someone decided to use EB as part of the reports. :-)) Reports never completed executing (timeout was set to 5 minutes). Today it takes 2 to 5 seconds for most filters and 15 seconds to return when the fewest amount of filters are used as reports have been moved to stored procs in the DB and ibatis is used to extract the resultset and display on jsp. In the above project, EB was misused. In your case you say that using EB would put you in danger of not meeting requirements. Is it not possible to know this before deciding on a technology?? Please excuse my lack of knowledge of agile methods. To me when someone discusses agile, all I can think of is someone building a working model of a car everytime the designer come up with a clay model. It just does not make sense. Sure you would build a car after the design has been decided upon and there will be changes along the way. However, a company only builds a working prototype when the design is shall I say almost done.
  11. Re: thanks!![ Go to top ]

    In your case you say that using EB would put you in danger of not meeting requirements. Is it not possible to know this before deciding on a technology??
    It is simple. The requirements changed, and the ripple effect of those changes put us in a position where entity beans would no longer meet our needs. It is tempting to say that we should not have started work until all the requirements are known, but the business units' understanding of what they need and the market in which the product would compete continued to evolve as project progressed. Trying to impose a waterfall model in which all requirements are known in advance leads to one of two outcomes: either nothing is built because of analysis paralysis or the wrong system is built because the customer was not able to express exactly what they needed before development began. This software exists to meet a business need for my client, so the process has to be tailored to ensure we meet that need. That means that we deliver functionality early and often and stay in constant contact with the customer representatives who can speak for the business units. This helps clarify the needs of the business units and allows us to converge on a solution iteratively while applying gradual course corrections based on customer feedback.
    Please excuse my lack of knowledge of agile methods. To me when someone discusses agile, all I can think of is someone building a working model of a car everytime the designer come up with a clay model. It just does not make sense.

    Sure you would build a car after the design has been decided upon and there will be changes along the way. However, a company only builds a working prototype when the design is shall I say almost done.
    I cannot really comment on this, as I cannot see how it relates to agile methods. In fact, I would say this is the exact opposite of agile software development practices. Building a working model for each change is akin to the "big design up front" that agile methods seek to avoid.
  12. A lot of information between the lines ...
  13. A lot of information between the lines ...
    +1 PJ Murray, CodeFutures Software Data Access Objects and Service Data Objects