Re: BCNGroup Roadmap for Semantic Technology Adoption

Yes, you're reinforcing the points I am making. Obviously within cyclical
trends there are cultures within companies that buck that trend. They are
the ones that may end up the winners.
Overall there is a lot more that could be discussed about the way companies
go about these things, which are management issues. Whether they are
discussed in those circles I don't know.
But it is an interesting point that, as an ontology depends on domain
expertise plus glue, these issues may legitimately impinge here, within the
sphere of interest of this list.
Adam

On 07/04/06, Andrew S. Townley <andrew.townley@bearingpoint.com> wrote:
>
>
> Hi Adam,
>
> On Thu, 2006-04-06 at 23:48, adasal wrote:
> > I had thought that these things may go in cycles, possibly fashion,
> > possibly economic influence.
>
> and:
> > It seems there has been a drift away from design methodologies, I know
> > I have made a conscious decision in this direction, but think about
> > the use of POJOs, test driven development and so forth in Java.
> > Moreover, in the end, it is the code that counts, that is what brings
> > the money in for a company, so programmers are trained to think of
> > being productive as the production of code artifacts. That there isn't
> > a clear separation between architects, designers and builders is
> > probably a mark of the immaturity of the software industryas well, I
> > don't know.
>
> Be careful here.  Some of what you've actually described (test-driven
> development, for example) *are* parts of methodologies.  As you say,
> these things are cyclical, but I think it's worth noting that (as you
> mentioned in another reply), some of the research Microsoft is sinking
> money into is around trying to reverse the current cycle somewhat and
> reinforce the good things we've learned as an industry through the
> development of Agile methodologies while at the same time trying to move
> things back to a little more structure.  It's a tough balance to strike,
> but there are those that believe it can be done successfully (myself
> included).
>
> You also mention a point about programmers being trained to think of
> code artifacts being directly proportional to revenue generation.  This
> is true, but only to a point.  Remember your software economics (Boehm);
> there are always trade-offs involved.  The only way that focus on code
> delivery and code delivery alone can possibly make sense (in a naive
> way) is in short-term financial terms for a license and support-based
> software company.  The economics come in when you figure the total cost
> of ownership of a piece of software through the entire lifecycle.
>
> Even in the license-based model, if poor quality software is delivered
> at high costs, the company may make additional revenue from consulting
> and support engagements.  However, unless they do something about the
> quality of the software overall, they will eventually lose customers
> (killing the goose that lays the golden eggs).  Microsoft* learned this
> lesson about security (eventually), because people chose other platforms
> and the press an Internet articles were eroding their customers'
> confidence.  Eventually, license-based software companies will need to
> consider the same sort of decisions if they want to stay in business.
>
> If you're not license based and it's an internal IT project, this is a
> lot more relevant to your overall operational budget.  You are only
> hurting your own bottom line, even if you may make the project delivery
> dates.  There are some strategic reasons you might choose to do this,
> but if you do, you'd better have a plan on how to get out of it in the
> near future.
>
> Of course, the trade-offs must be made based on the type and scope of
> the project involved.  Prototypes, demos, proofs-of-concept, etc. have
> different rules.  For some of these considerations, see [1] & [2], but
> the overall point is that you (or the organization that pays you) will
> eventually have to live with the consequences of the choices they make.
>
> Don't get me wrong, I'm not saying that Agile is bad or any other
> particular methodology is good, but I am saying that what I see in the
> industry right now is a lot of people who don't tend to have an
> awareness of how the pieces fit together (and I'm not trying to pick on
> you, Adam :).  This is a *bad thing* because it hurts the entire
> industry.
>
> So, really, I'm just advising you (and anyone else) to be careful and
> think about the trade-offs you make when you're writing code.
>
> Cheers,
>
> ast
>
> * Those who know me will be amazed that I actually used Microsoft twice
> in one email in a positive light. :) Personally, I'm a little amazed as
> well, but, in some areas, they have made conscious efforts to fix some
> of their faults, so you have to give them credit where credit it due.
>
> [1]
>
> http://www.joelonsoftware.com/printerFriendly/articles/SetYourPriorities.html
> [2]
>
> http://www.joelonsoftware.com/printerFriendly/articles/PickingShipDate.html
>
> --
> Join me in Dubrovnik, Croatia on May 8-10th when I will be speaking at
> InfoSeCon 2006.  For more information, see www.infosecon.org.
>
>
> ***************************************************************************************************
> The information in this email is confidential and may be legally
> privileged.  Access to this email by anyone other than the intended
> addressee is unauthorized.  If you are not the intended recipient of this
> message, any review, disclosure, copying, distribution, retention, or any
> action taken or omitted to be taken in reliance on it is prohibited and may
> be unlawful.  If you are not the intended recipient, please reply to or
> forward a copy of this message to the sender and delete the message, any
> attachments, and any copies thereof from your system.
>
> ***************************************************************************************************
>