The pre-publication version of this paper has been superseded by the final copy-edited version.
Software Research and the Industry
Dirk Riehle’s blog about everything computer science, applied and more
Twitter Feed- dirkriehle: Wow, thanks to @ChuckSmith @calipidder @deborahh for all the good advice on coping with unwanted cats in your backyard!
- dirkriehle: I'm a few days outta town and the neighborhood cats already seem to think they own my backyard. Where's my airgun? Alternative ideas welcome
- dirkriehle: Wife to returning husband at SFO: "You look so German now." Yeah right, Lederhosen. I declare all Germans wear Lederhosen so I can sneak by
Where Next?
4 responses so far ↓
1 Bernd Eckenfels // Jul 22, 2008 at 12:26 am
Software forges are basically enabling teams in maintaining intranet web infrastructure. This self service speeds up setting up team infrastructure however it can also cause a goverance problem for product development.
Bernd
2 Dirk Riehle // Jul 22, 2008 at 12:32 am
@Bernd: What governance problems have you experienced/are you expecting?
3 Bernd Eckenfels // Jul 22, 2008 at 2:12 pm
for example different code layouts, different meanings to severities of bugs and tasks. No aggregated view over multiple projects. In addition to that dependency management of software artifacts is a big one. And well.. release management might also be a biggy.
People like QA or technical writers working on multiple projects will have to adopt to each projects “style”.
So some infrastructure (like dedicated CVS/SVN repository) is better not used, right?
Maybe it is generally better for inhouse point solutions (as opposed to product development).
Gruss
Bernd
4 Dirk Riehle // Jul 22, 2008 at 6:51 pm
I’m not sure I understand. Wrt tools and integration, forges are like CASE tools and have significant benefits over a set of non-integrated tools.
In fact, I’d argue that because the meta-data is in one place, the forge database, and the different tools are at known locations, it is much easier to get a comprehensive overview across projects. If you don’t have something like this, but only have a bug tracker here, a config mgmt over there, etc. you loose the integration.
As to other aspects like coding guidelines etc. I think these are outside the scope of CASE tools or forges or a standardized but not integrated tool collection.
In general, I think, if you want to enforce certain behavior or process, you can always implement it, whether a forge or not.
Thanks for your comments!
Leave a Comment