Talk:97 Things Every Software Architect Should Know - Revision history

Ncarnova: Removing all content from page

Ncarnova — Fri, 16 May 2008 14:15:48 GMT

Removing all content from page

←Older revision		Revision as of 14:15, 16 May 2008
Line 1:		Line 1:
-	== Sometimes it's better to let the train pass you by ==

-	* Sometimes it's better to let the train pass you by *
-
-	There are thousands of "bits of wisdom" out there about how to make a software project successful. All of us have read them or often heard them discussed. As Architects we review them from time-to-time and gloss over the truth in them.
-
-	What is not found is solid recommendations as to what constitutes a software project doomed to fail. After all, one person's failure might be another person's success, right?
-
-	One reason for the lack of direction concerning identifying a doomed project is that the traits differ widely due to many different factors. Any attempt to identify a list of these that could be expected to exist in all cases is an attempt in vain. Due to the nature of our responsibilities as Architects we usually sit in the best position to determine that a software project is doomed.
-
-	We all have our own motivation for doing what we do. For some it's the challenge of building things that work. For some it's money. For some it's simply that we can, so we do. For others it's a combination of these things and others. Regardless of the motivation, as an Architect you will one day be placed in the un-enviable position of deciding if you care to watch the ship sink.
-
-	More to come....

Ncarnova: Sometimes it's better to let the train pass you by

Ncarnova — Fri, 16 May 2008 14:14:41 GMT

Sometimes it's better to let the train pass you by

New page

== Sometimes it's better to let the train pass you by ==

*** Sometimes it's better to let the train pass you by ***

There are thousands of "bits of wisdom" out there about how to make a software project successful. All of us have read them or often heard them discussed. As Architects we review them from time-to-time and gloss over the truth in them.

What is not found is solid recommendations as to what constitutes a software project doomed to fail. After all, one person's failure might be another person's success, right?

One reason for the lack of direction concerning identifying a doomed project is that the traits differ widely due to many different factors. Any attempt to identify a list of these that could be expected to exist in all cases is an attempt in vain. Due to the nature of our responsibilities as Architects we usually sit in the best position to determine that a software project is doomed.

We all have our own motivation for doing what we do. For some it's the challenge of building things that work. For some it's money. For some it's simply that we can, so we do. For others it's a combination of these things and others. Regardless of the motivation, as an Architect you will one day be placed in the un-enviable position of deciding if you care to watch the ship sink.

More to come....