Win a copy of Rust Web Development this week in the Other Languages forum!

Don Morgan

Ranch Hand
+ Follow
since Jul 24, 2003
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Don Morgan

Sometimes things like this, particularly if they are very small, simple, and/or single use, are easier to do in a little shell script instead of a full blown java program.
It is possible to just print the stack trace without explicitly throwing an exception at all, (which is sometimes useful for debugging). This can be placed within a finally block too.

[ June 21, 2007: Message edited by: Don Morgan ]
14 years ago
I spent many years working in the Toronto area and had the opportunity to work on excellent projects with great people.

You may also want to consider working in Western Canada. Alberta, and, to a lesser extent Saskatchewan, are both booming now.
15 years ago
It may be difficult to write tests for the inhouse frameworks, especially the validation of the test results, if you don't know how the modules are supposed to behave.

Some other thoughts:
* find code examples in your system or others which use the framework (grep is your friend!). Nice framework developers usually provide these.
* review the source code for the frameworks

I'm not sure how much they will help you, but these have worked well for me when in a similar situation. Make sure your examples and source are for the same version of the framework you are using.
Normalization is often one of the first things thrown out in order to improve performance...

Without knowing more, it is hard to tell if having so many items in the constructor is good or bad. Can some of the arguments be grouped together into objects themselves, and then use a composition relationship?
I usually think of loosely coupled/highly cohesive. If your classes are "loosely coupled" to one another, than a change to one is less likely to ripple through to other classes.

Booch and Rational have since embraced almost all the agile ideas, maybe because they believe it, maybe because marketing required it.
I've read and heard Booch say the main thing he doesn't buy is "emergent architecture." Last I heard, he still thought it was worth doing more architecture up front than agile leaders might.

Four or five years ago I was at a conference where there was a panel discussion. The panel was setup like a heavy weight championship bout. In one corner, there was one of the creators of RUP, and, in the other corner, they had a similar expert/spokesperson/evangelist from the XP Camp.

It turned out to be more of a love-in than a slugfest. What surprised me the most about the ensueing discussion was that even though the crowd tried to provoke a disagreement or argument between the two sides, it really seemed that both sides were more in agreement than anything else.

I am not surprised about RUP embracing agile ideas. Also, I find more and more approaches where agile blends in a *little* more upfront design and analysis.
One of the best ways to improve your coding speed is to slow down. Slown down and take the time to:

* make sure you understand the technology you are using. A few hours spent reading a manual or a good book can save days or weeks of "trial and error" programming.

* ask questions. This is another big lever where a few minutes spent talking to someone can save you hours or days of work.

* do your work carefully and encourage others on your team to do the same. Often it is the rework and debugging which drag down productivity.

These things seem like common sense, but is it surprising how often they are neglected.
Besides the hardware loss, the wetware riding the plane is a terrific loss too!

You are right though, using some of the agile methods for developing an airplane does not make much sense - the software world is quite different.
One other one....

* There may also be cases in hardware oriented or embedded systems where the requirements for the software are almost completely defined by the higher level system requirements, in which case it may not make too much sense to start coding until a good portion of the overall system requirements are well understood, and a SDLC may work better than a strict Agile process. I would need to think more about this though...

Also, the term SDLC is used quite loosely in industry. I have seen it applied to everything ranging from more of a waterfall type process to incremental and iterative development.
Here are a few cases:

* If your team works well already using SDLC, and you are given a critical project, similar to other projects done in the past, with the same team, you may want to stick with what works. (note there are alot of conditions here). Perhaps later explore if Agile works better for you, but this would not be the time to change.

* If the business you are in requires a strict SDLC (say for auditing reasons in the medical, aerospace or nuclear industry), you need to follow the required SDLC. I suppose it is just a personal preference, but I would not want to be on the first flight on a 747 which was "able" to fly at the end of the first week of development (I can just see it now, a couple of people standing beside a crash site... "That test failed. I guess we'd better start work on the landing functionality next week!").

* If there are legal consequences and a legal need to assign blame if the software project fails, is late, or for the consequences of defects in the software. (documents leave a much better trail than undocumented discussion). Obviously though this is not the right frame of mind to approach a software project.

* If you are outsourcing/offshoring a large development project and want it done fixed cost.

And the smaller and more detailed the tasks in your list, the more likely they are to become obsolete/wrong before you get to actually implementing them.

Change is fine. Keep in mind we are talking about a task list for estimates, not implementation level requirements. Estimates for smaller pieces of work are generally more accurate than estimates for larger pieces of work and usually lead to more accurate overall project schedules.

Without adding some detail to our discussion, I am not sure how much we agree (or disagree). This will vary a lot from project to project, but here are my thoughts:

* if the overall project is person-months of effort, try go down to the level of detail of days per task

* if the overall project is person-years of effort, try go down to the level of detail of weeks per task

Do you think this is too detailed?
Sure Stan, the real world relationships are more of a starting point than the complete model.

The CD example you gave illustrates how in some cases the "real world" should be respected. In the real world, a CD does not change just because it is put in a shopping cart (if it did that would make shopping really confusing!), and this does point toward the solution you chose. Unless they were trying to illustrate an antipattern, I don't know how the instructor could recommend having separate classes.
Usually inheritance works well if it actually matches the real world relationship you are modeling. Inheritance is prominent in many patterns, such as the Template method pattern.

There is nothing (much) inherently wrong with inheritance, but like anything else it can be misused. The most common objection raised regarding inheritance is that it introduces some coupling between the base class and any derived classes and that this can lead to "brittle" class hierarchies. This is true, but even with Composition there is coupling, either to a concrete class or through the interface.

It is ok to *prefer* composition to inheritance, but not to blindly choose one over the other.
I am curious what you need the timing information for? If all you are doing is trying to measure the performance of your system or something like that, it may be much simpler to use timestamped log messages for analysis. Is there something unique in the business logic, say like an order number, which you could use to match up the requests and responses from the backend?

Not sure if you already have a db in your system, but if you do, another approach is to insert timestamped events into the database (with rows of data something like UniqueID, TimeStamp, EventID), and then you can use simple queries to get your timing information.