and it begins...
December 7, 2005 4:35 PM Subscribe
DevFilter: For those of you who have started large-scale software development projects, what worked during the initial design & framework stages? Did UML->C++ work for the class framework? Was UML remotely worth it (my first instinct is no, but I've never done a project this big before). Other ideas? Things you'd do differently next time?
Aside from a few quirks, Rational Rose is indeed cool. Whether it saved time or not, perhaps. I suspect UML saves time if you or someone on the team is extremely well-versed in it and have much experience using it with other projects. So, I guess I'm saying that its utility might increase over time.
The best method I've seen is to get a team with a grasp of OO diagramming principles and getting to work on a whiteboard or paper, hashing things out. Break your system into subsystems and divy across the developers, define the interfaces, have a strong architect to guide the direction and interfaces, and get something working early.
Do early design work (if you system interacts with other systems, or you know people who have developed similar systems, invite representatives from those groups to participate in some of your design meetings), do some proof-of-concept work (which will change your view of the design), revisit and tune the design, lightly implement key components, make adjustments to the design as needed, finish the first stab at the implementation. Especially in complex systems, designs almost always need to change as development progresses. You learn things you didn't know. Allow for it in schedules.
Make sure nobody goes nuts with C++. It's a great language (one of the best) but if you don't have disciplined developers, it is a trainwreck waiting to happen. Debugging someone else's overloaded operator soup is a nightmare usually best solved by re-writing the whole mess.
Large systems die horrible and expensive deaths after long development cycles when they're burdened with too much process. I recently saw a project in another division take forever, cost $300M, use UML and every other neato tool and process under the sun, absorb nearly all developers in their division (hundreds), fail miserably, and lead to laying people off and outsourcing everything within reach just to recover from the wasted costs.
Get things working fast and smart. Where it makes sense, phase your efforts so you can declare victory often and build confidence.
posted by mumeishi at 5:42 PM on December 7, 2005
The best method I've seen is to get a team with a grasp of OO diagramming principles and getting to work on a whiteboard or paper, hashing things out. Break your system into subsystems and divy across the developers, define the interfaces, have a strong architect to guide the direction and interfaces, and get something working early.
Do early design work (if you system interacts with other systems, or you know people who have developed similar systems, invite representatives from those groups to participate in some of your design meetings), do some proof-of-concept work (which will change your view of the design), revisit and tune the design, lightly implement key components, make adjustments to the design as needed, finish the first stab at the implementation. Especially in complex systems, designs almost always need to change as development progresses. You learn things you didn't know. Allow for it in schedules.
Make sure nobody goes nuts with C++. It's a great language (one of the best) but if you don't have disciplined developers, it is a trainwreck waiting to happen. Debugging someone else's overloaded operator soup is a nightmare usually best solved by re-writing the whole mess.
Large systems die horrible and expensive deaths after long development cycles when they're burdened with too much process. I recently saw a project in another division take forever, cost $300M, use UML and every other neato tool and process under the sun, absorb nearly all developers in their division (hundreds), fail miserably, and lead to laying people off and outsourcing everything within reach just to recover from the wasted costs.
Get things working fast and smart. Where it makes sense, phase your efforts so you can declare victory often and build confidence.
posted by mumeishi at 5:42 PM on December 7, 2005
If you're all the same room then whiteboarding sessions will work better than UML for expressing software structure. Take photos of the whiteboard and put them on a wiki. Diagram and prototype and keep it changing until you like it.
As you can probably tell I tend to agree with the XP approach.
posted by holloway at 7:34 PM on December 7, 2005
As you can probably tell I tend to agree with the XP approach.
posted by holloway at 7:34 PM on December 7, 2005
Large scale development? XP? I think that's heading down a long hard road. XP is nice for small, maybe medium sized projects where you can get a prototype up and running in a few days, and add on to it from there. But a large project requires a detailed design, before making changes becomes a headache. How are you going make modifications a year from now if the core of your system was hacked together in a few weeks?
I would do some research on proven design patterns, and use a UML tool to play around with implementing one. This book ("Gang of Four") is a good place to start. As for UML, I'm using Visual Paradigm on Linux right now. It's nice but it's a bit expensive, I think. There is a 30 day free trial, though.
posted by SweetJesus at 8:02 PM on December 7, 2005
I would do some research on proven design patterns, and use a UML tool to play around with implementing one. This book ("Gang of Four") is a good place to start. As for UML, I'm using Visual Paradigm on Linux right now. It's nice but it's a bit expensive, I think. There is a 30 day free trial, though.
posted by SweetJesus at 8:02 PM on December 7, 2005
What's your definition of large-scale? How many developers? How much money? How much time?
I'd recommend good clear docs over UML. I've never seen it used usefully. Maybe using Dia or something similar could help at the start, but unless you have something that keeps it up to date all the time automatically it is going to be a hassle.
Automatic doc generation with doxygen or similar and some highish level design docs may be better and a lot cheaper.
Read the Pragmatic Programmer if you can. It's the best book I've ever read about developing software.
posted by sien at 8:28 PM on December 7, 2005
I'd recommend good clear docs over UML. I've never seen it used usefully. Maybe using Dia or something similar could help at the start, but unless you have something that keeps it up to date all the time automatically it is going to be a hassle.
Automatic doc generation with doxygen or similar and some highish level design docs may be better and a lot cheaper.
Read the Pragmatic Programmer if you can. It's the best book I've ever read about developing software.
posted by sien at 8:28 PM on December 7, 2005
I've found object models (simplified, only showing important objects and methods) and sequence diagrams (showing important but hard to understand code paths) useful in the past. I think that the problem that many UML proponents take it _way_ too far and model absolutely everything. You should model only the things that are difficult to understand. It also helps if everyone understands a common notation, so that when you go up to a whiteboard and start sketching, people aren't asking you how a line with a black diamond at one end is different than one with a white diamond.
posted by freshgroundpepper at 2:11 AM on December 8, 2005
posted by freshgroundpepper at 2:11 AM on December 8, 2005
enterprise architect is a rational rose on the cheap. it's amazingly good for the price. try the free download - if you've not used something like this before, you may be surprised to find that it does more than "pictures"; in particular it makes sure that all the different kinds of pictures you develop are self-consistent. so when you add a method in a sequence diagram, it automatically appears in your class diagram, for example. for a good introductory book on uml (thin, to the point, pragmatic, easy to read, and useful as a reference) try fowler's uml distilled.
however, uml and the related editors are just tools. what you want is a process. that process may use uml or may not, but finding a decent process - one that is suitable for your particular set of circumstances - is much more important than the tools you use.
a process should described (this is off the top of my head, you'll probably find something better via google):
- how you find out what your requirements are
- how you agree those requirements with your client
- how you get from requirements to a design
- how you transfer responsibility for design decisions up the food chain ("low level" nerds typically have the information to make decisions, but they need to be approved by "high level" phbs)
- how you document that process so that you can explain it later
- how you implement the design
- how you track progress of the work
- how the work is divided up and how different sub-teams communicate
- how you test the code
- how you integrate the code
a typical big decision in choosing a process is how often you iterate (how much design you do up front, for example) and how many levels you iterate on (you can have iterations inside iterations...)
uml can help with a lot of that, and various processes have been designed with uml in mind. maybe the most famous is the rational unified process.
however, that (RUP) is probably overkill. so to start i really recommend that you get fowler's book, since it covers both uml and a little bit of process. it's only about 150 pages of fairly large type, so you can read it in a day, and it'll show you much more clearly how uml can be part of a practical process. once you've done that, go back to the list above and think about what he didn't cover, and what might be important for you.
my own personal viewpoint on uml - it depends a lot on how many people you have and how much "churn" you expect during the project. a couple of people don't need uml, except maybe to sketch out ideas if they happen to like using it. but in a big company where people are coming into the project part way through, it think it can be a big help, since it can provide documentation that is tightly integrated with the code, and which (if structured well) ties high and low level views together nicely. having said that, we've so far failed to meet that ideal.
and focussing on uml rather than process is not good. a much more healthy question would have been "we are thinking of a process that uses uml and i'm concerned that..." or "what process should i be using for a project that..." (i'm not trying to tell you that you're an idiot, just trying to help you sort the wood from the trees).
posted by andrew cooke at 4:32 AM on December 8, 2005
however, uml and the related editors are just tools. what you want is a process. that process may use uml or may not, but finding a decent process - one that is suitable for your particular set of circumstances - is much more important than the tools you use.
a process should described (this is off the top of my head, you'll probably find something better via google):
- how you find out what your requirements are
- how you agree those requirements with your client
- how you get from requirements to a design
- how you transfer responsibility for design decisions up the food chain ("low level" nerds typically have the information to make decisions, but they need to be approved by "high level" phbs)
- how you document that process so that you can explain it later
- how you implement the design
- how you track progress of the work
- how the work is divided up and how different sub-teams communicate
- how you test the code
- how you integrate the code
a typical big decision in choosing a process is how often you iterate (how much design you do up front, for example) and how many levels you iterate on (you can have iterations inside iterations...)
uml can help with a lot of that, and various processes have been designed with uml in mind. maybe the most famous is the rational unified process.
however, that (RUP) is probably overkill. so to start i really recommend that you get fowler's book, since it covers both uml and a little bit of process. it's only about 150 pages of fairly large type, so you can read it in a day, and it'll show you much more clearly how uml can be part of a practical process. once you've done that, go back to the list above and think about what he didn't cover, and what might be important for you.
my own personal viewpoint on uml - it depends a lot on how many people you have and how much "churn" you expect during the project. a couple of people don't need uml, except maybe to sketch out ideas if they happen to like using it. but in a big company where people are coming into the project part way through, it think it can be a big help, since it can provide documentation that is tightly integrated with the code, and which (if structured well) ties high and low level views together nicely. having said that, we've so far failed to meet that ideal.
and focussing on uml rather than process is not good. a much more healthy question would have been "we are thinking of a process that uses uml and i'm concerned that..." or "what process should i be using for a project that..." (i'm not trying to tell you that you're an idiot, just trying to help you sort the wood from the trees).
posted by andrew cooke at 4:32 AM on December 8, 2005
I second freshgroundpepper's comment, and I also vote for Fowler's UML Distilled. Fowler's Patterns of Enterprise Application Development is also worthwhile if this is a standard business app of some kind - it will save you a lot of re-inventing the wheel. UML, imho, has a useful role in providing a common language to discuss the object model without implementing it right away.
Really think about where you can break the system into sub-systems and try to put in interfaces (ie where the clients of the interface can't assume how it's implemented) at those points: you may lose some performance, but you'll massively improve your ability to change and test individual parts. Developers can also work more independently on each side of the interface.
Do use iterative development, even if you don't use XP. It's much easier to change course if you get feedback on working features, rather than deliver the whole lot and then find its fundamentally flawed.
posted by crocomancer at 6:03 AM on December 8, 2005
Really think about where you can break the system into sub-systems and try to put in interfaces (ie where the clients of the interface can't assume how it's implemented) at those points: you may lose some performance, but you'll massively improve your ability to change and test individual parts. Developers can also work more independently on each side of the interface.
Do use iterative development, even if you don't use XP. It's much easier to change course if you get feedback on working features, rather than deliver the whole lot and then find its fundamentally flawed.
posted by crocomancer at 6:03 AM on December 8, 2005
I think UML is somewhat useful if you have people that already understand it and need to collaborate with other external teams which makes the formalization useful. If you are only designing something within your team, you can take some of the diagram types from UML and not worry about all of the specific bits of notation. You might also want to look at something like CRC Cards, which I think have been picked up by the Extreme/Agile community as well. I would really recommend that early group discussions take place around a whiteboard or a set of post-its or something else more fluid than any kind of diagramming tool.
The patterns books mentioned above are good, but again, it is difficult to get people up to speed on all of that if they weren't there already. You'll have to learn much of those lessons the hard way - which means the main thing you need to worry about is splitting the project up into isolated pieces (or layers) that you can redo individually later once you find out what didn't work.
Make sure to include time for things like unit testing, security, internationalization, and performance instrumenting from the start, because you will need it at some point even if you don't right now, so it is better to put those hooks in at the beginning. Start with small, achievable goals so you can see progress more quickly. Remember that the final integration of pieces always takes longer than expected, and nothing is really "trivial" until it is actually done and has been demonstrated to work.
Don't worry so much about tools - worry about the process you will follow and whether your team members understand their part in it. Make sure people know when to raise issues with other people. And make sure all the decisions you are making are documented, because you will forget exactly why something was done if it isn't written down.
posted by babar at 1:02 PM on December 8, 2005
The patterns books mentioned above are good, but again, it is difficult to get people up to speed on all of that if they weren't there already. You'll have to learn much of those lessons the hard way - which means the main thing you need to worry about is splitting the project up into isolated pieces (or layers) that you can redo individually later once you find out what didn't work.
Make sure to include time for things like unit testing, security, internationalization, and performance instrumenting from the start, because you will need it at some point even if you don't right now, so it is better to put those hooks in at the beginning. Start with small, achievable goals so you can see progress more quickly. Remember that the final integration of pieces always takes longer than expected, and nothing is really "trivial" until it is actually done and has been demonstrated to work.
Don't worry so much about tools - worry about the process you will follow and whether your team members understand their part in it. Make sure people know when to raise issues with other people. And make sure all the decisions you are making are documented, because you will forget exactly why something was done if it isn't written down.
posted by babar at 1:02 PM on December 8, 2005
This thread is closed to new comments.
We were using Rational Rose. A cooler piece of development software, I have never seen.
Every other time the team on which I was a member tried a UML system, it failed to save any time, promote any sort of organization, and was inevitably discarded half-way through the project.
posted by thanotopsis at 4:58 PM on December 7, 2005