Return To Forever

went to see Chic Corea and Return to Forever last night at the Mann Music Center in Philly.

the show was unbelievable. these guys didn’t skip a beat. al di meola still moves his fingers faster than humanly possible. stanley clark — who i think basically invented slap bass/lead bass — blew me away. they had their instruments either identical to the late 70s, or — in Chic’s case — modern marvels are able to replicate the precise sounds of some of those no-longer-in-existence keyboards and synths.

bela fleck was the opening act. these guys are awesome and have one of the premier bass players in the world. but RTF made the flecktones seem amateur in skill (and believe me, they are not! bela and the ‘tones are an incredible mix of 4 virtuousos)

i just kept shaking my head in disbelief at what i was witnessing up close and personal. first row, center, just behind the orchestra section of seating thanks to my friend Clay and his VIP pass! i think we had the best seats in the house. close enough to see all the detail, but not too close where you miss the wider aspects of the whole band.

you could see utter joy in the band member’s eyes as they hammered out the songs. in a jazz setting, and sitting close, you can really see the tremendous on-stage communication that goes on between the band members. it was especially fun when they would do the classic guitar-piano duels, or bass-piano duels. Chic would slam down an incredible riff, then stanley or al would follow up with a mimic, and “up the ante” maybe with a bit more. back and forth they would go until i figured their instruments — or hands — would be on fire.

though they were all very appreciative (and humbled) of the audience and the cheering throngs, they have it wrong. i believe (for me for sure), that it is we, the fans, that are truly blessed and thankful to have been in their midst for at least one night. an unforgettable evening of music genius that just does not come around too often in one’s lifetime. it would be like hearing mozart live. (and i don’t say this lightly.) i am so very grateful!

oh, and i won a prize during the trivia game! the 2008 tour book (or whatever you call it — thing with photos and their tour dates). quotes like:

* “It was a moment… the four of hadn’t been together in the same space since the 70s. But when we get into the throes of playing, it’s right back to that zone. It feels pretty fresh.” — Chic Corea

* “This reunion is going to really be nice. All of us have been practicing… because the music is demanding even at this point to me.” — Stanley Clarke

* “So many years have passed since we last played together. I’m a different person and play differently. We all do. In fact, when we sat and listened to our old albums, there were times when even we, ourselves, couldn’t believe some of the things we were physically pulling off. There’s something to be said about youth and envy.” — Al DiMeola

* “Playing together again was like riding a bike. It sounded great from the first rehearsal. We had to re-familiarize ourselves with the notes — we haven’t played them in 25 years.” — Lenny White

it was truly amazing music. every song got a standing ovation. some of the most demanding music you would ever hear — or see. and the crowd knew it and appreciated it.

i continue to bask in the soul-stirring glow of the immeasurable grace and beauty of the RTF notes left hanging in the stratosphere. thank you!

Requirements Traceability Matrix

In the agile modeling forum, the subject of a “Traceability Matrix” (TM) was broached.

Fabio asked:

I am trying to elaborate a traceability matrix, of the functionalities of the system that I work with. I would like to know if someone has an example on how I can elaborate this traceability matrix. I have a draft of this matrix, that I did, but I would like some ideas, so I can improve the matrix that I elaborated.

The traceability matrix will be used more by the QA team, but I think it can be useful for the whole it team. And with the traceability matrix, any requirement changes that may be developed we know exactly where the changes are affecting taking a look at the matrix. With the matrix we will also build up our test cases.

IMHO, the TM is a holy grail of an idea. In my years of working with building tools like Together, I got requests now and then for building a Traceability feature. The first one I recall was from a big company in Texas, maybe defense related, I forget (circa 1998 or 99). I asked for details behind why they wanted it and what is was supposed to solve. I didn’t get a very good answer.

Since that time, others asked for it here and there. Though I had technology at my fingertips to build traceability into Together tools, I never found the feature worth justifying the cost. (And yes, it has to do with relating a Test to the feature, and doing code tracing…) A few years back, when I was with OptimalJ (an MDA tool), and we added SteelTrace as a front-end requirements tool. There was a technical way to relate a requirement down to the lines of code.

But so what does it buy you?

While the concept seems appealing at first glance, reality often bites. It is hard to maintain, of exponentially diminishing value as the required level detail increases. In all my years, I never once was shown an example of a TM in practice that was used for anything remotely justifying its expense.

However, that doesn’t mean that a TM is not useful to somebody, I just never ran into that group or person(s).

My suggestion, Fabio, is to revisit the true needs of the organization. Then see what is the best way to get those needs satisfied. Should some form of traceability matrix be useful, I suggest starting small and inexpensive. See what you can get easily, and see if it is useful. Conversely, think of “prototyping” the end result of a TM. Pretend to use it for some scenario for which your organization thinks it would be useful. Explore alternative ways to achieve the same result (classic manual code searching, step-wise debugger, reverse-engineering sequence diagrams, or even code-based tools that allow insane levels of search — some recent web-based offerings that i don’t recall off the top of my head). Typically, the hardest things to find that might be impacted by a requirements change (nuances of data storage, little XML tweaks here or there, meta data, resource files, things generally non-discoverable in just the source code), are not tracked in a TM anyhow.

There are many ways other than a TM to keep the team informed of how requirements are implemented through the application. Acceptance Tests that prove the existence of a specific feature are one way. Design documents and models are another — assuming you do a good job at naming things to make it clear that a method in a class is named a lot like the english language of the expected requirement. A wiki can help keep these documents front and center.

IMHO, the best way to keep the QA team informed about the detailed impact of requirements changes is through developer communication (both in the issue comments and verbally as required). And, IMO there are two schools of thought regarding keeping QA informed of details. One is that an informed QA group that knows (via the developer) that a code change they just did for Reqt X, may have caused some havoc over in Reqt B, allows the QA team to please hammer those tests for B just in case. The other QA group is to be “blind” to details of the code changes, and simply do tests and ensure things still work.

RIA as a part of Agile

part of the struggle with conversing on a topic as broad as UX in or outside the ASD loop is one of “size.”

for reasonably “straightforward” features that require UX design, a couple of iterations is usually sufficient to get to a good place. my steps are typically:

  • understanding the basic requirement (e.g., we need to use a special service to look up critical special info from a ZIP code as part of a custom address UI),
  • the domain details (often down to methods/sequence diagrams),
  • some dynamic behavior of how the UI might interact with the domain model/server (after zip is entered, make a server call, get the linked lists of the related objects), and a
  • rough sketch.

When to spawn a separate UX project

if the team senses that:

  • UX is a major and critical aspect of the final product (as something like the iPhone probably was),
  • the design is very complex,
  • “getting it right” will impact greatly on the success or failure of the product,
  • there is a need to explore a handful of design ideas before committing…

well, sounds like you need to have a project to do this effort unto itself.

The UI is Independent of Domain

In general and virtually “always,” while the “UX Big Design” project is underway, the rest of the team can carry on with much of the other part of the system development. The UI — regardless of the complexity or simplicity of the UX design — is rather independent of the server or domain side of the world. So, even tho my project may have a parallel cool UX design component going on with its own features/iterations, i have all of the features still visible in the iterations through what I termed the “Rough UI.”

Whether the feature is surfaced in an ugly, simple UI control world, or a slick Flex/RIA world matters little. The core “back-end” API still needs to function. As the fancy UI components get finalized, they can be connected to the real API one by one.

Soon the ugly duckling UI turns into a beautiful swan.

WISKY

more folks should follow the WISKY principle… NOT!

(Why Isn’t Somebody Koding Yet?)

in 1995, my team and i were architecting a C++ solution for IBM’s next-generation manufacturing software. i had a crack team of 6 senior engineers/developers.

while i was gathering requirements and building object models, sketching UI ideas, and doing release planning; others on the team were building out (coding) the technical architecture we envisaged for this radical, thin client system. i also had my team setting up some real world simulation tests to thrash the architecture about, poke and prod it, and see if it was robust enough for our use.

the client was getting restless/antsy… they wanted to get moving on development of the whole app. they wondered “why aren’t more people coding? won’t we finish sooner if you have a couple dozen people working from the start?” but in reality, it seemed they wanted to bring on the dozen or so developers that were allocated and start billing them out and to report some “progress”.

i remember telling management “flat out” that if they insisted on bringing forth the horde of developers, the developers would just sit there and do nothing until my team and i were ready for them. i explained that this up-front work was essential to getting the team propelled in the right direction, with the right architecture, and consistent coding standards and coding templates. i also mentioned that this normally required about 10% of the project effort.

i got my way. no WISKY was allowed! (Allowing a bunch of developers to begin to develop prior to understanding the architecture, coding patterns, and the basic priorities is a big mistake.)

A few weeks later, we were ready to begin and brought in the other developers. By that time, we had our thin-client, layered architecture determined, and a pattern for folks to follow.

(footnote: the 3 months upfront was pretty close to that 10% mark, for the project ended up being ~3 years, ~250 domain classes, and ~1 Million LOC. This was my first large “agile” project.)

The Cost of Complexity

In reading this very nice post from Manoel Pimentel Medeiros, I am reminded of another value I ascribe to simplicity — “quick-and-dirty” can be a valuable technique.

Many times, when faced with some very complex issues in my projects (usually surrounding integration with bizarro other systems), I strive to have developers take a very simple approach at first. Sometimes these approaches seem like hacks, inelegant, and the exact opposite of what I normally practice. Sometimes I can tell it is hard for the developers to do this “ugly” work. (Maybe they fear I will leave the ugly hack in place .)

However, this is a technique I use when the route is not clear, or when there are viable alternatives from which to choose. Or if we are probing for the right solution and are not confident if the chosen solution will work. So, instead of designing a more complex and elegant “correct” solution, I do the simplest thing. Maybe it means dummying up the data to achieve the effect. Maybe dummying up some objects. Hard coding. Passing in a fixed XML file to test the new format versus changing the code to generate it that way.

By choosing a simple solution *now*, the value is that we can get to evaluating the results and downstream impact of our ideas sooner rather than later. Once we determine that our solution will work, then we go about implementing it correctly. At times, though, we discover that the idea didn’t work as expected. So off we go to look for another solution.

So, simplicity can also be very useful when trying to quickly and cheaply determine the best course of action in creating a viable solution to some aspect of a problem you face.

Clear Vision?

A discussion came up about vision in the Agile Usability forum.

Like many things in software, it is always hard to discuss “things” without specific examples. The size or scope of the discussion has to match the circumstances. Design and “vision” for a single functin/feature is radically different than the design or vision of a “change the game” product. Timeframe can often be important… are we talking about year-long projects with 20 people? or decade-long projects with 2000 people? at any rate, even the latter can be broken down into small chunks of reasonably-sized sub-projects and shorter deliverables. in other words, in some sense, ideas about the role vision plays are/should be scalable…

do you find product owners have vision that spill beyond the purpose and needs of the system into disciplines like usability? architecture? maintainability? extensibility?

my experience has been one of working closely to collaborate as a partner with product owners or the “customer(s)” to blend their wants and desires into aspects of software design and usability that can then be conveyed to the team as a “vision.” the phrase “two heads are better than one” comes to mind.

setting the vision, conveying it to the team, allowing good ideas from any quarter, at any level in the project, at any time; but also staunchly defending the vision as needed. contradictory? maybe, but not really.

As far as the team and others peripherally involved grokking the vision… yeah, it requires constant repetition. “If I had a nickel for every time…” I write or speak the vision… I say it in scrums often. It is all over the wiki, whether you start from the “project vision/overview” pages, the FAQ pages, or the page titled ” Grokking ” and the subsection: “Grokking in a Flash!” with the quick links of “What”, “How”, and “When.”

The wiki is also a very useful place where i keep discussions, brainstorming, etc. New people come onto the project and may have “a great new idea” — like the other 5 before. So a gentle discussion and a wiki link can direct them to a wealth of corporate memory and explain why we may have considered that “great idea,” but chose a different path instead.

nonetheless, it is no small feat to carry a torch of a vision… requires continuous championing, occasional foot stomping, and lots of repetition, in my humble experience.

Programmers/Designers

In the Agile Modeling forum, we were discussing:

“With the exception of acknowledged apprentices, do I really want any of my coding done by anyone not good

enough to design? — Paul Oldfield”

I think it is a matter of scale / breadth.

For the full application, i see the entire design and how the pieces of the model fit together.

For the technical architecture, I look at a slice and see the pattern that needs to be followed by all parts.

For very gnarly parts of the application I usually work with the developer to design out a solution, starting with ideas, working with sequence diagrams, then code.

For specific tasks, a “programmer” will do more or less of the design themselves:

– as they are skilled/experienced

– as the task complexity demands

The only tasks that developers might do that require no design is when they follow the cookie cutter patterns established in the technical architecture patterns. For example, creating a new class that needs to follow the standard design pattern… the table DDL, the DAO, maybe a Data Gateway, a Business Object, a Transfer Object, etc. These sorts of repetitious patterns require little design for the “basics.” So the basic “CRUD” is often a pattern, or a framework config file… not much thinking required. (“It’s so easy even a tool can generate the code…” and “Consistency is a quality all to itself” phrases come to mind.)

As the tasks move to more novel elements, like implementing certain methods, or interacting with other classes, the complexity and uniqueness start to surface.

So, i would say that even the simplest development task that is accomplishing something novel in the application requires some level of design.

Caught Using Inheritance!

don’t fall off your chairs…

re: ” I have in the past had long debates over whether or not the domain

object should know about persistence at all.” (Agile Modeling forum)

but i have *successfully abused inheritance* in the past to achieve an

interesting mix (for thin client/web apps).

  • Xyz Domain Class
    • can live on server or client
    • has the usual: properties and accessors
    • business methods
    • associations to other objects
    • often employs lazy loading
    • knows NOTHING about DBs
  • Xyz Business Class
    • INHERITS from the Domain Class
      • Gets all of the class properties that way 🙂
    • Knows about persistence classed (DGs/DAOs)
    • has the persistent ID
    • can get itself from the DB via an ID
    • can save() itself to DB
  • Xyz Transfer Object
    • small thing to meet some need of going between UI and server
    • used typically when the Domain Object is too big and you

      want specialized sets of properties filled in

  • Xyz Identifier Class
    • really tiny thing
    • usually just an ID and a string
    • sometimes a few other things
    • used for lightweight lists of associated classes
      • to drive drop-downs
      • typically used in conjunction with lazy loading

<gulp> there, i’ve confessed.

Clear Specs

A recent email underscores why written specs are never sufficient to communicate complete details. (Now, throw in that both parties are not communicating in their native languages…)

Fair work, help for people

Good time of day. You are disturbed by the charitable company Redd Cross of Slovenia. We have the business offer for you. We can offer to you of earnings, thus your salary will make from 1000$ to 2000$ per one month, at an incomplete working day. Your earnings can be and higher. The more and forces you will give time, the there will be your salary more. If it is interesting to you, you write on the address of e-mail of our agent: agentcristilman@gmail.com he will contact you within 24 hours and will throw off to you all details, and will answer you on all your questions.

Thank you for attention Redd Cross of Slovenia!

My Favorites

  • Good time of day.
  • You are disturbed by the charitable company…
  • your salary…at an incomplete working day.
  • The more and forces you will give time…[the bigger your salary]

Makes me want to sign right up!

Software that works for its user’s “user!”

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!