*** WARNING ***
Massive rant coming
Maybe it is hormonal
*** WARNING ***
see below
<disclaimer>
- i started OO with first release of Turbo C++ (late 80s?)
- i began OO modeling in early 90s by hand/PPT/Excel
- i began using Together/C++ ver 1.0 in summer of 1994.
- i was a member of the original executive team
that formed TogetherSoft in 1999 with Peter Coad.
- i formed the mentoring team at TS in 99
- i was building a 2nd product sep 2000 - jan 2002
(new exec management team cancelled it)
- i sold lots of tools with mentoring on OOA and FDD
- i was involved with many of the features of
TCC up through 2002 (i tried to rescue it from
feature lust and QA nightmares)
- i am now involved with OptimalJ / an MDA tool
</disclaimer>
-- jon
-----Original Message-----
Sent: Saturday, January 31, 2004 8:12 AM
Subject: Re: [AM] Do tools sell?
Post by Jason GormanFolks
I've been mulling over this issue of why it's difficult to sell agile
development to senior IT managers, and one possible reason might be that
it's much easier to sell tools than practices. XML and web services have
Could it be because our industry does a poor job at building software? Could
it be because we do not keep track of results? It is virtually impossible to
estimate ROI on a process -- a tool is arguably easier to estimate ROI.
I remember fighting battles to change people over to OO. It is similar to
fighting for better process. "So, Mr. Smart Consultant, why is your OO
solution better than a structured approach? Can you prove it?"
Post by Jason Gormanspread like wildfire. There are easily many more UML modeling tools out
there than people who know OOA/D. The demand for .NET has been almost
instantaneous. xUnit is an order of magnitude bigger than TDD. And so
on. It seems to me that tools and technology are much more
quickly adopted
Post by Jason Gormanthan practices and processes. It seems that managers like their
solutions
Post by Jason Gormanto come in boxes with manuals. If it requires THEM to change the
way they
Post by Jason Gormanwork, then it doesn't seem to appeal as much.
Tools are easy for managers to understand.
Not the tools I sold/sell -- TCC, OptimalJ.
Development tools don't have an "end product" -- they are but a sculpture's
or painter's tool. In the hands of a skilled artisan, a tool can do wondrous
things. In the hands of an unskilled person: "A Fool with a Tool is Still a
Fool."
The same can be said about developers.
They are also much simpler to roll out because they typically
don't require a culture change.
Again, a tool like TCC or OptimalJ requires a change in process. If a team
is not familiar with modeling, or is not familiar with iterative
development, a tool could cause anxieties. Change is never easy.
Tools often have large organizations behind them with a marketing budget.
So does RUP...
Developers like playing with new toys, oops, I mean new tools.
A new process like XP or TDD or using "tools" like JUnit or ANT or XDoclet
or --- you get the point -- are also new things for developers to *play*
with. Not to mention, C++, Java, C##, Ruby, Python, TNL (the next language),
etc.
My cynicism: I wonder if our industry would be better off if we allowed our
developers to actually get good at something? The only core skill that
transgresses all of the alphabet soup of new tools, languages, cool things,
is
How to Do Development
Did we really need Java? Or just a better C++?
Did we really need C#, or just some improvements to Java?
What will supercede these (surely lousy to some) languages?
Technologies come and go. Not much is new under the sun. XML? Big whoop.
J2EE? Yeah, like distributed computing was never done before. Ant? For those
of us who thought we didn't have to use make/nmake ever again -- wrong. Web
Services -- wowie zowie. Now the world can be made a safer place.
When the F are we ever going to get around to building software fast and
software that meets users needs now and in the future?
Instead, we spend all of our time learning some freaking new technology when
we really never learned enough of the last greatest technology to be
proficient.
I wonder if any companies have the guts to stick with a technology long
enough to master it and profit from it? I wonder what the business
ramifications would be? What if you had a core team that was really very
good at just getting things done. Had a great business model, a great set of
tools and practices, and great respect among the business users for "just
making things work for the business."
I guess we'll have to wait for a new language or a new widget.
Post by Jason GormanIs it possible that MDA will outperform Agile because it's about tools?
Not a chance. MDA is doomed. See my next AM online column, likely going
out on Monday or Tuesday, from www.sdmagazine.com.
I would say this without any ties to OptimalJ. It is a matter of balancing
naysaying. In the first place, why would anyone in their right mind think
the nirvana goals of MDA aren't something to strive for as an industry?
Sure, they are pie in the sky, ivory tower things. But so what! IMHO, these
sorts of things provide a "gravitational pull" for our industry to get off
of its fat pimply ass and try to do things that result in business value.
Anyone who thinks that we are "fine" as an industry needs to get a lobotomy.
Unfortunately, this needs to be heard by the inverse of who reads this list!
Scott, your claim "MDA is doomed" is ludicrous. It's akin to saying Agile is
doomed. Or, modeling is doomed. Or J2EE is doomed. In the first place, "MDA"
is about as concrete as modeling and agile. You and I both know that Agile
is in the eye of the beholder (just ask Graham). You and I both know that
there is a far cry between how you and I model for pragmatic purposes, and
how a newbie drugged by Rational books models for improving paper stock
prices.
OptimalJ is not perfect by any stretch, But it does have just about one of
the most perfect concepts that I've seen. It needs to grow in the right
directions and make some of the concepts easier to use and alter.
Oh fair readers, can any of you deny that the following "tenets" should
apply for long-lived business applications?
1) You should model the business and keep Separation of Concerns front and
center (don't pollute layers of business, UI, persistence). If you don't
have a business layer, you are wasting customers money. You risk increased
time to market and decreased business agility for future enhancements,
maintenance.
2) Coding should be done in a repetitive boring manner, following
construction guidelines (technical architecture, code skeletons, naming
conventions). If you unleash a team of 20 developers on a project and hand
out assignments for features to be built, how do you direct them? Do you let
everyone guess on how to do persistence? Do you let everyone build the UI in
their own way? Or, do you have some form of consistency you strive for? Do
you have some standards for handling persistence? Maybe a framework? Maybe a
reference "slice" of the application? Maybe a word document with programmer
tips? If you do not follow consistent construction guidelines to develop an
application that provides thousands of features, you are likely developing a
pile of crap.
Don't forget -- running code is not sufficient to claim success! Would
anyone think that 5000-line JSPs riddled with SQL is a good thing? Lets say
it satisfies the requirements and the users agree it works! But, is it
maintainable? Is it easily extensible? Is the business model apparent? Of
course not... It is an embarrassment to all professional software
developers.
3) Application development must be done in an iterative manner, with
frequent, tangible working results.
Now... would it be nice to be able to have tool support for this? Something
to help you model the business? Something to help you automate the
repetitive aspects? Something to give you an agile environment to quickly
see what you're working on?
Post by Jason GormanCertainly, whenever I'm asked about my modeling skills, the words
"Rational" or "TogetherSoft" aren't far behind.
Yes, many people relate modeling to CASE tools. It's too bad.
It's one of
the things that I find truly offensive about the MDA because the MDA
reinforces this view of modeling.
MDA tries to make some things that can be expressed in a model form more
valuable as part of the code generation. Together did it by making my
sketches translate to code and vice versa. I found lots of value there. I'll
challenge anyone to a race at developing quality software -- I'll use my
tools, and the others can use their purely manual techniques.
If you have a whiteboard sketch of 250 business classes, how do you find
that valuable? How do you edit it?
How do you keep it in sync with the actual code? I know, you don't.
How do you get it into code?
How do you handle persistence? (Turn classes into tables?)
What about putting some of the domain model into a library for reuse?
Okay, digital photos, I guess.
Post by Jason GormanOn several occasions I think it's counted against me that I would
prefer to work on the whiteboard 95% of the time - because I'm
saying "we
Post by Jason Gormandon't need $5,000-worth of kit to be model-driven" - which not only
developers, but managers don't seem to want to hear.
There are no points awarded for how much manual labor you do.
For IBMs Manufacturing Execution System, I had 200-300 problem domain
classes (C++). I'll give you one guess as to whether I typed the tables in
by hand or not (and we had to support DB2 and Oracle).
If you think doing that by hand is a good idea, you will be outsourced
(where a low-wage worker can do it by hand).
Being pennywise on tools (that is why you get a desk and a computer) and
pound-foolish on delivering an application is not business savvy.
We don't need heroes on development teams, we need professionals who care
about business results.
Then perhaps it's a good way to identify people that you don't
want to work
for?
Post by Jason GormanHow does other people's experience compare with mine? Is it
easier to say
Post by Jason Gorman"let's get Rational" than "let's do a little design and then
build the thing"?
Well, maybe not Rational <g>.
I've worked in many organizations where management buys licenses from
Rational but then the tools sit on the shelves and we work mostly with
whiteboards anyway. I also have no doubt that there are hundred
of people on this list with the exact same experience.
This is what I fight against. Sales guys don't like me for it. However, not
every team is "man enough" to handle a tool like TCC or OJ. However, someone
who really understands how these tools work can use them as a secret
weapon -- this is how I won many millions of dollars worth of contracts.
However, tools have to be very extensible and malleable to fit into the
category of secret weapon.
My advice: let management spend their money however they want and let the
developer decide for themselves which tools they want to use in practice.
Easy for a small firm. Try that on for size in a firm with 20,000 developers
<g>. You and I may not care about developers using whatever, but there are
often people trying to standardize on such things in large orgs.
- Scott
====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html
www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com
TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------