This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Agile and Other Processes and the fly likes product development experience and project development experience Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "product development experience and project development experience" Watch "product development experience and project development experience" New topic
Author

product development experience and project development experience

Rr Kumaran
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
Hi All,

w.r.t professional experience in software development, what exactly is a product development experience and project development experience. I am working in a service based company rather than a product based company so what are the actual differences between the two ?


Thanks & Regards,
Bantumilli.


RR Kumaran
SCJP 1.4
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
In general, I would say the difference is that product development requires much more attention to maintainability and architecture than projects, which may be one-off solutions.

That's not to say that product development would require big, up-front architecture design. In fact, using XP might support the quality much better than a waterfallish method.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Richard Leavitt
Greenhorn

Joined: Jun 28, 2004
Posts: 2
I like Lasse's generalization. Other characteristics of *Product* development versus projects that I've noticed:

- Products have multiple releases
- Products tend to keep the same team together
- Products are revenue generating, not cost saving

I'm also seeing many IT shops split up their development into "products" and "projects." Products are those areas where they choose to create a competitive advantage, something they feel will help them win more business (e.g. a new provisioning system for distribution to channel partners). Projects are run in areas they want to achieve technical parity (e.g. implement a new packaged CRM application).

Hope that helps.
Richard
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Actually, in XP2004, Mary Poppendieck called out to the XP community to move into product development mind-set instead of the current project-oriented thinking. Martin Fowler echoed this in his closing keynote.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
In project management they define "project" as a set of tasks with a defined beginning, goal and end. So a project might produce several products or an incremental upgrade to a product. I guess I think of product oriented teams as having more of a "shrink wrap" mentality, perhaps delivering major releases to non-captive audiences infrequently. I live somewhere else - we can ship small upgrades and bug fixes and whatever else as often as we need to a captive corporate audience.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:
In general, I would say the difference is that product development requires much more attention to maintainability and architecture than projects, which may be one-off solutions.


This doesn't match my experience. I've never seen a user of a system who didn't want a good software system to be even more improved.

Similarly, every "prototype" I've seen did go into production for a while, regardless of what people told beforehand.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
This doesn't match my experience. I've never seen a user of a system who didn't want a good software system to be even more improved.

Well, I've seen some (and it wasn't about the system being perfect but about the system being good enough for nobody wanting to shell out extra dollars for improving it further).

Having said that, I really don't think we're disagreeing here -- or then I just don't understand what you're referring to?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Trying to clarify what I meant by
In general, I would say the difference is that product development requires much more attention to maintainability and architecture than projects, which may be one-off solutions:

If you're a product company, selling a product named WhizBang 5.0, WhizBang 6.1, WhizBang X, WhizBang 2009, etc., you typically can't afford to start every new version from scratch. Your architecture has to be in a good shape. Otherwise you'll end up open-sourcing your product in a desperate move to avoid bankruptcy after your product releases have slipped severely for many years in a row...

Then again, if you're a stovepipe company engaging in a bespoke development project building a piece of software that automates some mandatory but non-essential part of your company's operations, you might not have too strong an interest to invest too much into a rock-solid, nuke-proof architecture. In other words, you're not expecting to need major changes into the software being built (and the contractor might have his own profit margins in mind...) so the Good Enough bar tends to be lower compared to a product company.

Does this make sense?
 
Don't get me started about those stupid light bulbs.
 
subject: product development experience and project development experience