Slashdot Mirror
Developing Applications with Java and UML
Each chapter begins with a brief summary and a list of the goals. After reading the book through, both should be useful. Each chapter also closes with a 'checkpoint' that summarizes what has been covered in the chapter and what is to come.
The first chapter sets up the entire book by outlining some of the project problems encountered in software development. Once the author gets into development models, the Unified Process from Rational Software, a huge and detailed software process, is introduced. The book focuses on only using the elements that provide the biggest 'bang for the buck'. The Unified Process is the focal process of the book, but the Synergy Process is a free alternative, only lacking some additional guidelines and how-to's. A short overview of UML is covered, along with its' place is in the software process. He notes that a project that just uses UML in a vacuum without a sound process and plan will fail.
The second chapter briefly discusses the Java language alongside the concept of Object Oriented Programming. Experienced Java programmers could skip this section if they wished. The section is worth skimming as a lead-in to the explanation of how Java and UML are a good fit.
Chapter three, Starting the Project is the first time the book delves into the meat of how to structure a project. The example scenario that is followed through the book is introduced, and throughout the book real-world examples are used that relate to the sample project. Every theory in the book that is translated into some kind of example the reader can pull apart and examine.
Through the next few chapters use-cases and class diagrams are covered, leading up to building a user interface (UI) prototype. Personally, I've never used UML for anything but sculpting class diagrams for export. This is the point in the book where I started to see how the rest of the project is able to use UML and tie it all together. Being able to model the classes and easily export them is very powerful, but even more so when combined with the rest of the ways you can employ UML in your project.
The following chapters are much like the first few that began to talk about the sample project. There is no Java code until chapter 9, halfway through the book. This is not the book to get if you are only interested in how to use UML as a base to dump out some code.
Throughout the book the content remained interesting, and relevant. Do not expect to sit down and read it from beginning to end. There is a great deal of material covered and no topic that was inadequately explored. Using the sample project consistently throughout the process was invaluable, along with the samples and source code provided. Alongside the process, the real life anecdotes and comments provided were a welcome addition instead of an intrusion. The author is someone who's seen the mistakes that could be avoided. For example, an application with 70,000 lines of Java code that only contained two classes.
Having talked about the depth and detail of the book, this was also one of the bad points as well simply since it takes so long to get through. People already well experienced in running a project with similar phases will find it much faster reading. The other issue is the expense of the tools and products involved. Rational Rose, the Rational Unified Process and WebLogic are rather expensive products. Thankfully there are alternatives that he mentions in the book, and others as well. Visio, the Synergy Process and Tomcat are all possible alternates. Surprisingly, Tomcat is used in his example setup.
I had left the rating at 8 throughout most of my reading while considering the positives and negatives. However, when I finished the book I bumped the rating up to 9 simply because of the wealth of information I learned. Anyone aspiring to run a team project with Java should read this book. In the corporate arena, most of the battle is not the code, but understanding what the users want and what will be created. Following any kind of process will improve the result, even if only a few key elements are used.
Chapters:
1. The Project Dilemma
2. Java, Object-Oriented Analysis and Design, and UML
3. Starting the Project
4. Use-Cases
5. Classes
6. Building a User Interface Prototype
7. Dynamic Elements of the Application
8. The Technology Landscape
9. Data Persistence: Storing the Objects
10. Infrastructure and Architecture Review
11. Constructing a Solution: Servlets, JSP and JavaBeans
12. Constructing a Solution: Servlets, JSP and Enterprise JavaBeans
Appendix:
A. The Unified Project Plans
B. The Synergy Process Project Plan
C. Estimating Projects on the Basis of Use-Cases
D. Sample Project Output
E. BEA WebLogic Application Server
You can purchase Developing Applications with Java and UML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I like the concept of UML, it makes it easy to abstractly define an entire program and then quickly put it together in either C++ or Java.
Unfortunately though, there are a lot of programmers that that UML and instead of having the simple links between the methods and classes, they have these jumbled messes because... well actually I don't know why. I am thinking it is because they don't want to spend the time writing quality UML and instead program something that works. (I know the feeling, I hate designing before programming, but you need to do that if you want to make it easier to support in the future.)
The key reasons for UML and advances is exactly that though. You (and others) need to be able to easily support your code in the future. If it is a jumbled mess of spaghetti code, or even worse if it is a complex mess of command made solely to speed up the code that very few will comprehend. Then you end up with a large problem. When something needs to be changed, it becomes incredibly difficult to decide how to do it.
I agree Java is pretty slow (it has sped up a bit over the years, but it still isn't optimal), but these OOP concepts of UML and properly designing easy to understand code should be applied over a need for speed. Hell, if you want to speed up the code a bit more, use C++.
I think programmers need to stop worrying about speed so much, and start to realize that these programs need to be easily workable and last. UML provides just one more way to keep them easily managable.
~ kjrose
Surprisingly, Tomcat is used in his example setup.
Surprised? Most Java developers use Tomcat for a servlet app server (not a full blown app server, but you can have that if you tie-in JBoss). Tomcat is great for development if you aren't dealing with EJBs.
Most Java developers I know use Tomcat before an app server is chosen so they can get stuff working, and will stay with tomcat unless the customer has a license for an expensive appserver or they are using EJBs.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Paul Read's book is one of the most applicable, thorough, and "practiceable" UML books to date (and I have read a lot of them). One of the concepts that was a real breakthrough for me was the event list/table. There always seemed to be a step missing in the transition from a client requirements document to use cases, and the notion of the event list was it. A number of projects I've worked on have suffered from the use cases being far to granular, resulting in a nearly unmanageable number of them. The event list serves as the perfect tool for eliminating this problem.
While the sample project is not unnecessarily complex, it provides the level of detail necessary to apply RUP and UML to just about any Java project. Furthermore, most UML books fail to move beyond the theoretical level and provide concrete examples. This is not the case with Java and UML. This book is written in a style that is easy to read and will have you familiar with the concepts and applying them to your own projects in a matter of days.
Do you even lift?
These aren't the 'roids you're looking for.
Yeah, like that's ever going to happen. How would we know how elite a programmer was if he didn't just hear a problem and then work like a maniac for a week and pull a rabbit out of a hat? We can just work out the problems as they appear in the code as it is being produced. Easy.
;P
Besides, a formal, methodical approach to software development is just so... arty! Nothing for the macho h4x0r to sink his yellowing teeth into. Real programmers just grab some wood and nails and start hammering. I mean, how many buildings can you name that were built on paper first?
I've got a bad attitude and karma to burn. Go ahead. Mod me down.
If you want to buy the book, go to the Bookpool site, much cheaper. Here is the link.
But will they work with languages like C or Fortran?
now we need to go OSS in diesel cars
Java and systems are getting faster. Consumer products in Java are not an unrealisitc expectation. The author of the book even says you don't have to follow the complete process - the book just uses 10 out of 100+ artifacts. You can pick whatever works for you. If you are pumping out similar products having an already-defined path helps instead of hinders. It depends what process you've got in place. For a small app things like doing the UI prototype will take a day or two at most - and you won't need any of the extensive data steps. Scale to what you really need, don't pick up a book or process and follow it through blindly.
There's a saying in certain UML circles:
"Shit doesn't get smaller if you draw an UML diagram of the bowel that produced it."
UML gets a bad reputation because most people think that because they (spent a fortune and) got Rational Rose they suddenly know something about program design and software architecture.
For the experienced developer UML is just another addition to the toolbox. They understand when, but much more importantly, when NOT to use it.
And consumer software written in Java? Nope.
Ever used JBuilder?
D/L JBuilder 7 from borland. Yeah, your thinking its in C++, or at least mostly in C++. The whole thing's written in Java.
Java in consumer products have been invaiding, and you've thought it was C++ the whole time...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Speaking from experience, I can tell you that using UML and Java together can be a very rewarding (and timesaving) experience, so I applaud this book's direction. Whatever methodology you choose, I feel that software impelementation is only going to get better when companies realize that time spent doing discovery and design is as (or frequently more) important than the time spent coding. My current contract is just now learning this, the hard way...
They look pretty 'l33t to me
And me too. I was implying that truly elite programmers think about things deeply, then design, and THEN code. I have just noticed a tendency for geekdom to promote "seat of the pants" design. Which is right up there with improvisational interpretive dance with mimes.
I've got a bad attitude and karma to burn. Go ahead. Mod me down.
EJBs, when deployed in a J2EE-compliant EJB container provide a lot of services that would be difficult or time consuming to write yourself. Plus, there's 1000 books about the standard. You get transactions handled automatically, across any number of data sources, you get Object-Relational Mapping and all that that brings. You get connection pooling. You get a lot of stuff that you wouldn't want to write yourself. Plus, it's all remote, so you can have business logic stored in one place, with clients accessing it remotely, and always being in sync. This way you can write multiple client types (web, swing, pda) that all use the exact same business logic.
Yes, it can make simple things difficult, but it mostly makes difficult things simple. If you are creating a large system, you do NOT want to be hacking ASP, PERL, PHP or some other roll-your-own architecture, especially if you have a lot of engineers, not all of whom are senior programming Gods who can behave themselves in such wild-west environments (i.e. most serious projects).
http://www.naildrivin5.com/davec
If you throw away the UML when you move to the next phase, then the UML step was mostly wasted. I can do everything UML does by writting and reviewing my header files. UML is great, if you keep it up to date with the program because you can see all the data on one page (11x17 poster) that you hang on the wall.
Class A has a pointer to class B, which has a child C, containing a pointer to class D, and that is how class A and class D fit in the whole system.
Remember the Mythical Man Month quote: (Which I cannot find offhand, but something like this) show my your logic, but hide your datastructurs and I will be mystified. Show me your datastructures and you will not need to show me the logic, it will be obvious. UML is a nice way to show the data structures -- if it is kept up to date
I like UML. Having a few posters on my wall that defined my data structures made the changes in my logic obvious. Even when UML had some lacks that it was still obvious what I needed to do. (The implimentation I used did not support an array, and I had one problem which required writing an array to hardware) However I was always printing out new posters because something changed. Worse, I had to keep track of a different one for each version of the product in the field. Still it is much clearer to have the essence of the header files all on one page, than scattered about in many different files.
What of that do you really need? It seems like there are some pretty easy ways of getting connection pooling and transactions (maybe not declared in XML files) without that. Even clustering is simple if you can get your firewall to route the same people to the same machine, and if not, you just have to be a little overhead.
Given that a "Hello World" session bean takes about 6 or 7 different files, it's hard to believe it's making life simpler.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
(* I'm not very knowledgable about it, but it seems there isn't a clear tracable path from the use cases right down to the source code. It seems that UML results in work that is thrown away when moving forward in a project. *)
d =02/0 8/23/012255&tid=108 [remove spaces])
I am not sure exactly who the target audience is for UML. Managers? Developers?
I found the most important document is table scemas (DB layout). Whether it is represented as text (column dictionary) or an ER diagram does not really matter that much to me, although ER diagrams tend to skimp on details to make it fit on a single wall.
The rest of the stuff often covered in UML diagrams tends to be task-specific, so does not belong in a "global diagram" IMO. Then again, OOP tends to partitian things differently than relational-centric shops. (I won't start up another anti-OO rant, because we had plenty a week ago here at:
http://developers.slashdot.org/article.pl?si
Sometimes I use informal UI flow/state diagrams. If you get too formal, then you end up mixing high-level stuff with lower-level stuff and get a mess IMO. Save the low-level stuff for code.
Overall, it is important to keep the audience in mind when making such charts. You cannot fit everything for everybody for every viewpoint, so you must make some dicisions about the purpose of a given diagram or chart. (Unless you work for a place that requires them for no fricken purpose beyond burocratic rules.)
Table-ized A.I.
It has to be remembered that Use Cases are customer-centric. They are intended as a semi-formal communication medium which can be understood by customers, analysts, designers and developers.
As such, a system which realises a Use Case may look nothing like the Use Case.
On the other hand, an Object Oriented application is often best designed to mimic the "real world", so your objects and methods tend to drop straight out of a use case.
The usual technique is to take your annotated UML diagrams and pick out the nouns and verbs for each Case, filter them down to a minimal set, and those are (more or less) your objects and methods.
This still involves recapturing though, but this is unavoidable. It is dangerous to think in objects at an analysis level - you tend to make invalid assumptions without even realising it. e.g. A developer is a salaries employee and a cleaner is a wage earning employee. Now, where do you put the contact developer ...?
Because you can't capture the objects along with the requirements, you must identify object candidates from the requirements, and determine a suitable design in which they will interact correctly according to the actions/verbs/messages indicated by the requirements.
Then you have to consider everything that the users won't like, the managers will add because it may be useful, and the beancounters will strip. Ew, bad image.
UML is a descriptive language for the entire software process. It crosses domains for which there are no direct mappings ... and if there were, customers would be putting in Use Cases and getting out software, with MicroRational/RationalSoft Inc. in between.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
I think that you may have missed the connection between the different sets of diagrams in UML.
The use-cases don't stand by themselves. They just happen to be arguably the most high-level view of the application, and the closest to the process of answering the "what does the client want?" question.
The connection between the Class Diagrams and the Use Cases, from my point of view, is formed by the Sequence Diagrams. Each Sequence Diagram solves a Use Case through communications between entities from the Class Diagram.
The Sequence Diagrams translate quite directly to source code, and connects the source code to the Use Cases and therefore to the client's requirements.
Of course, that's assuming an ideal world where the requirements were correctly collected through the magic of Use Cases in the first place. More likely, by the time you get to Sequence Diagrams something is clearly terribly wrong and you have to correct the Use Cases and recollect requirements, etc.
The value of the Use Cases is not so much, I think, "making clear the requirements", but having a structured way of getting those requirements linked to the source code when you finally get them right.
Freedom is the freedom to say 2+2=4, everything else follows...
(* Then I wanted to ask, if anyone of you has already worked with UML in combination with PHP and MySQL. I've just started modelling my database along the UML profile for data modelling and like it so far. *)
:-)
Most PHP and MySQL shops are not into OOP that much (I did *not* say all). There is not much info out there on non-OO UML diagrams besides ER diagrams. The industry ignores those who think OOP is a pile of tangled, rigid, bloat-producing hype-crap and don't want to use it. Too bad there is not a publisher which specializes in closet OOP haters. (Well, I am certianly not in the closet on that one
Non-OOP software engineering is virtually ignored by the press and publishers, yet *many* shops still willingly ignore OOP or only pay lip-service to it in order to sound in-style.
(oop.ismad.com)
Table-ized A.I.
(* Fortran is procedural not oo; so no UML *)
Although UML is not *purely* for OO, it is biased towards it.
Like I say in the PHP message, the industry is currently biased toward OOP dispite the fact that many shops reject many OO concepts and show no signs of changing that aspect.
Non-OO'ers are nose-thumbed. Well, I finger OO in return. Get some fricken real OO evidence instead of brochure babble and we might just change.
Table-ized A.I.
From what I know, you can't do a full "UML design" without a CASE tool like Rational Rose. It doesn't appear directly on the diagrams, but you can specify relationships between diagrams that (I guess :) could make looking around the design really convenient.
For instance: you have feedback from a user, you need to change something. You figure out which actor the user is, then look at all his use cases and modify one or more. You then follow the tracability diagram to the realisations of those use cases - and you know which classes need modifying.
(* This book is for projects made in heaven - i.e. the defence and NASA contracts where there are tons of money. *)
NASA has money to burn? (Rocket pun not intended.) I don't think so. Perhaps you really meant "good at wasting money". IOW, it is the output process and not the input process.
UML diagrams can certianly turn into a money pit if you are looking for ways to increase your staff and look big and busy.
Perhaps a project that fails that has tons of diagrams to show for it will not look as bad if it fails and all the walls are empty. IOW, it is a manifestation to the superficial types that "at least we gave it a good effort".
It is yet another technique in politics-heavy orgs to fail yet not look bad.
I am waiting for the book, "How to bullshit your way to the top in IT". There is one about contractor scams and trickery, but I don't remember the name of it right now.
Table-ized A.I.
UML came about slightly before Java, and was itself developed as a common notation for existing practice - hence "Unified Modelling Language." The people behind UML used to push their own, incompatible notations.
UML itself encapsulates two basic techniques - use case driven design (modelling requirements almost entirely in terms of user actions) and OO design. I don't know about use cases, but OO was in it's infancy in the early 70s, and a usable OO environment (Smalltalk) existed by 1982. C++ came along a few years later.
It seems to me that what you are complaining about is the fact that the solution doesn't just pop automatically out of the problem description.
h tml might give you an idea where I'm coming from, but frankly I doubt it, I think you're probably beyond help.
"are there better notations out there that can further streamline the path from requirements to coding" is another way of saying, "I can draw a UML diagram, but I still need to think, isn't there some other way of doing it that cuts out the need to actually think entirely".
Well, no, there isn't. Furthermore, there never will be. I could say a lot more about this, but I won't. http://www.melloworld.com/Reciprocality/r0/index.
http://rareformnewmedia.com/
I use Dia whenever I want to draw a UML diagram. I wouldn't, however, use it if I ever had to do a full UML design. CASE tools (as opposed to drawing programs) give you a whole bunch of valuable navigation facilities, a higher degree of error checking etc.
Argo looks quite niceYou make it sound as though the majority of programmers are working on consumer applications. I don't have figures by my side to qualify this statements, but I'm sure the opposite is true.
It's not necessarily a phase! You don't need to do all the design before you start cutting code. Remember that UML is a notation, not a process like the Rational Unified Process, eXtreme Programming, etc.
"are there better notations out there that can further streamline the path from requirements to coding" is another way of saying, "I can draw a UML diagram, but I still need to think, isn't there some other way of doing it that cuts out the need to actually think entirely".
No, this isn't it at all. I'm just wondering if there is a way to capture requirements effectively (hard thinking intact) and have the results of that analysis in a form that can be dropped into the next phases of development. I'm not looking for magical solutions; I'm looking to cut out some of the redundant manual labor and the unnecessary buzzwords and fluff inherent to CASE tools.
Avoiding the issue by calling me "beyond help" does nothing more than make you look like an arrogant prick.
Healthcare article at Kuro5hin
It is designed for large systems, not Hello World applications. It is also designed as an architecture to direct development. I'd like to see you whip up database connection pooling and transaction management across any number of disparate database servers in a short amount of time and make it fully configurable.
I mean, by your logic, you don't need to rely on any standard or any pre-build system, because you can roll your own. Why use TCP/IP? I'm sure you can roll your own network protocol without all the "overhead" of the IP headers. I mean, to send one byte of data with TCP/IP requires 64 bytes!
Don't talk about things you know nothing about.
http://www.naildrivin5.com/davec
Don't talk about things you know nothing about.
Screw you jack; I know something about this. Not everything, but enough to talk rationally.
Yes, of course you can get ridiculous in a desire to remove layers of abstraction, but that doesn't mean EJBs (especially Entity beans) might not be too slow and complex for their own good. Otherwise there wouldn't be so much talk about JDO.
"make it fully configurable" is part of the problem...sometimes you do get better turnaround doing a series of smaller, customized solutions to problems than making or utilizing some huge, everything-but-the-kitchen-sink platform. "But it's XML! Non-programmers can change the flow!" Frankly, for anything non-trivial you usually don't want non-programmers changing the flow.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
It isn't up to the managers and designers to make sure the implementation is a good one. That is up to programmers. But the programmers CAN'T make a good piece of software out of a bad spec and bad design. That's like making a good movie from a bad script. I don't care WHO you cast, it is doomed from the start. Ditto s/w dev.
I've got a bad attitude and karma to burn. Go ahead. Mod me down.
The problems with UML tools is that they [sometimes] generate skeleton code out of your models, and then you go in and fill in the "meat". However, if you change the model then either you lose your changes (i.e.: the meat you put in after countless hours of effort) or you have to forget about changing the model with the tool and do changes yourself.
So what I think we need is some form of tool that always matches the model to what you're programming. More or less like what IDEs do when you're designing a GUI while the write code automatically to represent the GUI, while allowing you to change the GUI code and have those changes reflect in the GUI design itself.
With a tool like that, it could also be possible to generate a UML schema from your own spaguetti code, and then change the model visually, with the net efect that the tool would refactor your classes, method calls, variable names, and packages to match the model.
And of course, with a such a tool you could (and should for all new projects) start with the UML in visual mode, and then fill in the specific code.
Note that I've seen countless tools that claim to do this, but none of them really give you enough freedom to make changes on the code or in the model.
Why couldn't they fit it all into one class? It simplifies the UML, and you don't have to look in two different places for the code.
Geee... I thought UML was created to make money selling Rational-Rose and UML books!
I find it to be overly tricky as a graphical tool - at least if you use a lot of it. If you don't build big class hierarchies (and usually you shouldn't), javadoc lets you find the hierarchical information just fine, and it stays up to date as the code changes.
My favorite graphical device, as another poster stated, is the Entity Relationship Diagram, which captures the data heart of the sorts of projects I do.
OTOH I have a friend who works for a company that uses UML from one end of a project to another and thinks it is wonderful and produces a very efficient development environment.
Oh well...
The only good weather is bad weather.
Well it looks like I'm going to be buying another book. I've been looking for a good way to document object-oriented programs for a LONG time. I've heard about UML and browsed a few web pages but just didn't really understand it well enough to see it's value. Maybe this book will get me through the learning curve.
Could someone who really understands UML tell me if it will handle documenting object-oriented programs that use third party objects? For example, if I code something using Borland's Kylix, I may not have the source code to some of the components that I'll be using. How does one effectively document in this situation?
The race isn't always to the swift... but that's the way to bet!
Right, I'm obviously a "luser" because I replied to a post that may have come from a complete beginner. You of course are not a "luser" because you insulted me for trying to be helpful. You're not a luser just a complete jerk.
The race isn't always to the swift... but that's the way to bet!
Problem is, when PHB sees book in store, suddenly what is methodology becomes "magic potion" (at least the PHB thinks it is) in the office.
now we need to go OSS in diesel cars
Yeah! Instead of solving the problem and implementing business logic just stuff it into some inflexible transaction-driven model written in a language composed of multiple idiosyncrasies of its authors, and call it a solution.
It's yet another one-size-fits-all solution for people that can't design their way out of a wet paper bag -- it is for software development what "wizards" are for system administration.
Contrary to the popular belief, there indeed is no God.
Disclaimer: I haven't read this book, but I have read many in the Addison-Wesley series on UML, RUP, etc.
Can't agree with you at all. Once you have more then a handful of members on a development team a process of some type is necessary. Otherwise you have people wandering off doing their own thing and duplicating work, or contravening major design principles.
I have personally used UML and a modification of the RUP process for projects under $50,000. My team delivered these projects under tight time and budget constraints. Without the ability to design ideas and document them ahead of time I feel we would have wasted significant time and blown the dead lines out of the water. This doesn't fly with clients.
Unfortunately some people, mainly clients, think creating diagrams of the system is busy work. I've found the easiest way to deal with that is to share the diagrams with clients and explain them as you go. This works good with activity diagrams that illustrate business processes. This helps catch errors in our perception of what the clients want before any code is commited. Once you explain that to the client they are generally sold.
The other things is unless you have a process of some type you are bound to forget things. Things will slip through the cracks. Things will get off radar. A process and UML help keep things organized.
So, I would say that the real world requires something like the Rational Unified Process once yet have more programmers than fit in a VW Bug, or you get over a handful of classes.
MarkX
I've been told by people at TogetherSoft (maybe it was just marketing bull) that they use Together and Feature Driven Development (developed by Peter Coad) to develop the Together products.
cheers
Java programmers do it with
Obvious Guy pointed out how there is the idea of good design first then implementation, but in reality it is much different. However, lets not accept that attitude and practice anymore than we would accept the regular practice of someone robbing your house when you leave during the day and saying it was simply 'a sad reality we must learn to live with.' I have sadly worked for some of the worst managers and development teams that you can get... these people make disorganized and pr0n addled teenagers hacking together a toy look like the giants in the industry as far as coordination, collaboration, actual planning and consistency are concerned. This problem of short time delays ends up forcing horrible hack jobs that we call proof of concepts, which predictably leads to being told to turn it into a formal prototype with only about a month, then told there that said prototype is now the system once we use the 2 months to harden it. Those time periods include the testing and documentation as well. Result? Most often a very hard coded, fragile, spit and bubblegum system that only causes massive heartache and money to maintain, extend and adapt not just a year later but often immediately following release. (most often because of adaptations to particular environments, platform settups, security requirements, etc of various end sights) When questioned on this, the pavlovian response of the decision makers is that the needs dictated this and they "could not" wait. Its been my experience that this is either an outright lie or is just extremely poor judgement. Consider how a project could be hurried up like this and end up a mess, yet when you look at the actual tasking orders that led to the project it clearly states (well clearly for bureacrats) that this is an advanced proof of concept to be fleshed out and refined before being adopted officially. Hmmm, does that mean that they want crap that takes 2.5 times the original development effort to turn into a useful and robust? (extensible, maintainable, efficient, buzz buzz buzz)
I put this under the category of 'never learns from mistakes' as this happens so regularly yet so many on both sides (especially on the user side) complain about the lack of interoperability, extendability, and integration worthiness of these projects. So, to make a long post short... (too late, I know) what kind of book, cbt, cute PowerPoint slide, or dancing furry vendor mascot will get the point across the program managment and self labled 'system engineers' that it is both cheaper and more productive in the mid to long term to really plan, design and implement an actual piece of engineering rather than these hack jobs held together by dirty bandaids and mucous. I know that as an integrator it would make my job easier :) As a customer of various products though, I would be extremely happy and of course its not like I never have to maintain, much less develop in an environment that while contains talented programmers is not held together by anyone (or any ideology) that will coordinate, motivate and lead everyone to a satisfying conclusion. Actually its been so long sense I have been able to say, "Yeah I worked my tail off but we did our best, produced some impressive results and can be proud of the work we produced" Hmmm, lets check Monster.com now :)
I seek not only to follow in the footsteps of the men of old, I seek the things they sought.
The instustry[sic] is lacking decent metrics right now, so disagreements are popping up all over the place.
y code=66:101&islowerlevel=1
Your ignorance is only out weighed by your ego.
Metrics for OO Software Engineering have been around for years. Just because you have never heard of them does not mean they do not exist. If you spent as much time reading as trolling perhaps you would already know this.
Here are a few links to be going on with: http://www.dacs.dtic.mil/databases/url/key.hts?ke
Software engineering is a dark-grey art (as apposed to a black art). As soon as one realizes this, things will start to look different.
The siren call of hacking and the fundamental difference between an amateur craft discipline and a professional engineering discipline. Let me guess; Self-Taught! The oxymoronic mantra of the incompetant.
Take your ignorant trolling elsewhere.
Compare this and this
This is copied from Amazon as well.
Someone else noticed that, but his comments got buried in level 2 of this thread. (so I'm aware, that my posting is redundant, but hopefully someone will mod this up and warn people).
Remember: Never take slashot or amazon ratings too serious.
-- "As a human being I claim the right to be widely inconsistent", John Peel