Steve Gordon posited the following in response to the original poster thinking about

Original Post:

I explained in a simple words as possible the competitive advantage they could get if they give agile a chance, so I hope they will agree on a pilot project. Otherwise, how can they tell if they like chocolate cake without tasting it?

Steve replies:

With no measurable problems, what would be the success criteria of a pilot project anyway? Do you really expect them to adopt agile just because they liked a taste of it, even though it did not measurably improve anything?

IMHO, lack of “measurement” is the albatross around IT’s neck…

heck, i can’t even prove why my design is better than the next guy’s with anything other than a damn sure guarantee that his design will be worse. I base this solely on experience. Yeah, I suppose I could throw out a few metrics… but tying those to “success” or cost is hard to do. One of the problems is that BOTH solutions will work. I know he could get his solution to work, but I am also pretty sure it would be overkill, a nightmare to maintain, and difficult to extend.

I am tempted to put up the two competing examples and get folks to comment… one of these days.

This is generally not so difficult to do in a “hard” engineering discipline. One can usually compute costs of two solutions, roll forward estimates of how each design will cover future scenarios, determine the value proposition going forward, and choose which solution is best for business.

Until we get to this point in Software Engineering, it will forever be a fool’s challenge to “prove” one solution/process is the right way to go. (Not to mention the excessive variability to software that is inherent in its very nature.)

This is a great parable about agile development.

Rocks into Gold

Share it with your “management” or clients that might need a boost to their understanding of what agile could become… if people embrace the concepts.

A young developer and their team want to go the agile route… Innocently asking for some examples of complete project documentation from which to learn… spurned me to thinking if it is even possible to “see” agile without being a part of “doing” agile.

kind of an “Agile-is-in-the-eye-of-the-beholder” thing…

So, below is a scrubbed view of the wiki to date for a project. Is the project agile?

Out of the blue, I get a call this morning from Eric Theoret — since it shows up as Quebec on my phone, I decide to answer. I have some very good friends and associates in Quebec… It could have been Jean-Claude or Mathieu!

On Sunday, I had placed an internet order with MacMall (I used to do all sorts of business with PCMall with 4 PCs in the house, but now i have 2 iMacs for home and a MacBook Pro as a my development/work laptop).

Eric (an Account Executive) noticed my order and saw that a 1 TeraByte HD was back-ordered. Through his energy and knowledge of various support software, Eric was able to find a HD (which the internet system was unable to locate) and add it into my order. So he called me to tell me…

Eric also mentioned how he gets into work every day before most folks, and puts in some extra time looking over the accounts and seeing what he can do to help. Well, his ability to help was very much appreciated — now i’ll get my stuff sooner.

I must say, I was very impressed:

• with eric’s personal drive
• that he proactively found a missing part of my order
• and that there was good “back office” software at Mac/PCMall to allow Eric to learn about my account (he saw it stemmed from the TogetherSoft days) and really provide quality customer service.

Kudos to Eric and MacMall!

Hope he doesn’t mind, but if you need anything computer-related you can reach him from North America at 1-800-555-MALL ext 8542. Without a lot of fuss or muss, I have always found good prices and selection and quick response from Mac/PCMall… now Eric has raised the bar even further.

As a software development guy, I like to think of the software and integration and workflow that all goes into something as seemingly “simple” as what Eric was able to do.

Think about that next time you design some software… many times the benefactor is twice removed from the user!

so why is it that, despite warning signs going off in my head, little angels on my shoulder screaming, i let myself get into the weeds on a project?

when you are in the weeds:

• you don’t lead
• you don’t steer
• you don’t allow others of the team to step up and pick up that ball
• you only get a temporary boost
• you can’t sustain it
• you don’t blog
• you don’t hang out on forums

i have bonked myself on the head!

back to sustainable pace!!

Some recent discussions revolved going back and forth on DESIGN.

For me… design is a multi-faceted thing… Sometimes it is a very high-level part of the overarching theme of what drives an application’s details. Generally, the design is the means by which superior business advantage is gained by our clients.

• For an insurance agent portal application (gather data about the insurance requirements and submit…) we are building now, one of the running jokes is “Everything is a Question.” That is because my overarching design of the system is a domain model surrounding the questionnaire aspect of the system. Add to the questions meta data for the rating system (to auto-generate the XML stream for rating). The entire UI is driven dynamically by the questions set up in a questionnaire — the sample questionnaire that demonstrates all API features and rules is a Diner! Need a piece of information sent to the backend rating system? Create a hidden question and some rules to assign the answer. Need a fancier UI for some questions? Add a CUSTOM_UI meta tag and the UI will kick off a different component for that question(s).
• For a patient clinical summary system we designed, the overarching technical aspect of this design was the “Form” — basically a set of information needed for a patient. Working backward from this request, the proper data was pulled in by autonomous agents, shoved into a “worksheet” for processing. This multi-agent system used descriptive “Semantic Web” technologies such as RDF and OWL for knowledge representation, mapping, and processing.
• For a fire department web-based preplanning system, i used a very brute force technique to implement 50 domain objects in J2EE. Though the 2-tier menu system is table driven, the bulk of the beans are repetitive. Yes, I thought about MDA. Yes, I thought about building it in a completely meta driven manner. But, this was a homegrown, entrepreneurial project, so we used a proven and simple technique that I could deliver more rapidly.

For the first two cases above, the combination of design ideas, sketches, wiki explanations and code will give you the fastest ticket to joining the team and becoming productive.

For the 3rd example, you could jump in on examining source code for any of the 50 objects and know all there is to know about the design and start coding.

design is in the eye of the beholder also… the facets of the design that you choose to share are generally for a specific reason. Maybe for the stakeholder to understand the business value that an advanced design provides… Or, a combination of showing the application architecture + the domain models + code samples for the entire set of layers for the technical architecture is what is best for developers. To discuss the UI design, that is a whole other ballgame.

Another way I like to think about folks (like Ron Jeffries) considering the “Code IS the design:”

• code is reality
design is intent

do you see much software engineering in your travels?

in chatting with the Sun guys behind the new UML effort in NetBeans, i thought of the following. i have often wondered what has caused such a dearth of interest in software engineering and using modeling tools:

• the focus on hurry up, get it done/get started coding?
• people trained in hammering nails, but who have no clue about true engineering
• a lack of “connecting the dots” between stakeholders/management and what is truly needed for doing software engineering, hence illusions of progress in app development projects, and the lack of transparency into the true cost of lousy-engineering
• over hyping of tools like Rational’s — which didn’t really work as well as advertised — causing a backlash due to the disillusionment of management/development teams
• people getting stuck in over analysis and modeling without a purpose
• the creation of architect roles by people who could not really understand building the code and therefore were relegated by the team into non-essential folks who sit in the corner
• tools that did not give good ROI
• tools that tried to do too much
• later versions of Together fell victim to this (feature lust) and i couldn’t convince peter coad to not include such features

just some random thoughts…