Again, any opinions or what might seem like opinions expressed here are meant as entertainment and in no way reflect anything believed or doubted, supported or disavowed by any companies I am currently working with. This is my sandbox. We all need a sandbox.

Quick example I use time and time again: the notion of a Dog. Picture Dog in your head. Come on now, do yourself a favor and do me a favor and play along here. It wont hurt your brain.

Go ahead. Picture Dog. For those who find the idea of a Dog a bit much and do not understand what I am asking you to do, you are essentially defining what a Dog is in your mind as it may appear in Webster’s. At the same time, we will show (because there are eight of us here), you are simultaneously making grave assumptions and positing them as inextricable truths. People use this to sell software, car polish, and even the idea of a 50k marriage ceremony.

Most likely you pictured a four-legged creature with teeth, a tail, two ears, fur, and all those things that make up Dog. Now think of every dog (lowercase) you have ever known. Do any of them exactly match your idea of Dog? If one happens to, more than one cannot. What color fur does Dog have? What if I shave it off? Still a dog? What about the dog that lost a leg or was born deformed? Still a Dog? We, and science (which attempts in vain and endless desperation to accommodate what we learn as we go along) have the uncanny and quite handy ability to say, “Sure, that is a ‘Dog with Three Legs’” and I hope you see where I am going with this. It is not until something becomes real, tangible, interactive, of this world, removed from the ethereal and Universal conceptualization that we are actually talking about the world we live in.

In the beginning, there were fatty acid chains. Phospholipids (this is dish soap… strings of fats). One day in a land far far away a bunch of them found water, and the water excited the ability of these chains to attach to each other until one bent unto itself unto itself unto itself. This happened a whole bunch of times. At least 11. Suddenly, one happened to capture something inside of it. I went outside and swung a butterfly net in empty air with no butterflies in sight. On the 138th swing, my shoulder was burning but inside that net was a leaf. True story. Really.

There are those that believe this is how life was created. I will not get into that here because apparently, I have been told my blog posts are already making some people uncomfortable when it comes to matters of Universals and similar. Still, it is perfectly plausible that at one point, micelles (balls of these lipids) formed and captured something inside of them. Try this with liquid soap and a bowl of pepper or (*wink*) iron shavings… you may find you get soap bubbles that appear to move towards something as though they had a will of their own and as they form and form again, more and more properties will be introduced. Call it accident, call it evolution, call it crazy, just dont call it late for dinner. Evolution is not thoughtful all the time, nor does it have to stem from God or anything besides what we know as nature and refer to as Nature (all of everything in this example, and something I cannot define because as soon as I do, I make it amorphous). The overarching point is, with simple building blocks and the right environment amazing things can happen.

Likewise, as those amazing things happen, you get objects like heavy soap bubbles. These might not last so long, full of iron shavings and bumping against each other. What actually happened is that one of these bubbles was caught in *gasp* ANOTHER bubble and something called a liposome was formed (a bilayer, really). The liposome looks a heck of a lot like a cell and a cell membrane or the earth and it’s atmosphere. Amazing. Yes it is. Ever notice how Cheerios seem to find each other in a bowl of milk? Hmmmmmm? There is veracity in simplicity and constraint in hard definition. You know this if you have read a Statement of Work with any kind of reasonable level of technical professionalism. I am, like, REALLY good at that stuff. Good at eating Cheerios, too. They dont find each other as easily when buried in sugar, however. Not many things do besides ants and other vermin.

Fast forward a few billion years because I would bore myself: somewhere down the line machines came into being. There was the wheel, then the spoke, gear, pulley, and I am sure I am not sure how manufacturing evolved but the notion that Toyota mastered it is insane. Muda is a cute little catchphrase Agilists throw around and Emo Agilists have tattooed in Chinese on their ankles in order to sound smarter than they are. It does not take a genius to realize there is such a thing as waste and yeah – it is not good unless it produces something useful and then well, I guess it is not quite muda anymore, is it?

More tricks of language and making things that are ‘specialized for a purpose’:  if there was not Waste, there would not be Efficiency, would there? No Up without Down and no magnetic micelles that develop a flagellum without plain old fatty acid chains. And no aqueous environments to make it happen in without non-aqueous environments. There would just be Environment. And, environment. How boring and impossible. It is not the Uncertainty Principle, and I have only heard myself say it, but as soon as you look at or have perspective on something, it is defined within the constraints of the senses. This is where imagination and the discipline of knowing when to say WHEN is important.

Do you remember Dog? Think of him again. Come back, Doggie.

Is he in your head? Dog? Mr. Dog? Come, boy.

Did you see a Him because I said think of Him? Was it the same Dog you thought of before? Did you have free thought or were your seemingly undemanding and agnostic parameters more constraining than you originally might have thought? I do not know about you, but I can be guided by language and choice of words. You can too. I just said I didnt know about you so I would not sound like a snot. We all are. Ever sit on Santa’s lap? That was the lap of deceit. Scary. Watch out for fat old men who call out for kids to come here and sit on their lap.

Point being, we work with what we have and we move along trying to become better. The “trying to become better” part has yet to be addressed. This pursuit of “being better” is legit, but what is not legit is the mandate that one way of becoming better is better than another. Better not say that again or I better get a thesaurus. Most of the time we try to become better so we can make money. Motivation is of utmost importanance and please please please keep it in the back of your mind as you buy a product versus forming a relationship.

I used one word: “better” with at least 3 different meanings but without introducing a change of meaning. One word with so many manifestations. How is that possible? Assumption? Context? Do we start with a blank slate and fill in what works when the answer is not cut and dry?

It is possible to have multiplicity within simplicity and it happens because of advantages handed down and the movement of grunts and gestures to a language with context, multiplicity, and extensibility (see where I am going yet?) built in. It is not about the word and it is not about the fatty acid chain. It is about what can be done with them. It is about the mistakes and the muda and the collisions and the serendipity. It is about potential and integration with something real, something Agile. Stop claiming that Scrum is an Agile model. Going to the bathroom is an Agile model. You are impressing nobody besides your bankers. This is innate human ability we have had to be trained OUT OF.

And this was true long before the Agile Manifesto was written by a bunch of guys looking to make a buck on essentially branding a natural process within a “technical” arena. This idea is ridiculous. What is the most misunderstood, incomprehensibly powerful and undefinable network of circuity known to humankind? The brain. Not the Quad Core. I would like to see us spend less time on inventing a faster cable and more time looking at the bottom of the sea or at the brain. The brain, mostly. Fact is, we are intimidated by it. All of us but the bravest of souls who are willing to go with a slim paycheck for the pursuit of Betterment. Bless you, you geeky little misfits.

Agile took a nice firm foothold when Visual development tools became common. Why the sudden reversion to the simple and the contextual, encapsulated, phospholipid? By forcing code to be organized in a visual manner and in the creation of objects and OOP, we could build touchpoints, mini APIs, and components that could be reused or tossed out or better yet, placed in a class library of some sort. Viola! There was a way to codify something. Humans loooooove codifying. It kind of, in some odd way, makes us Master of that which we examine. It is silly. We are a silly species. UML is a great example of taking this a step further and I will admit, UML makes me breathe heavy. True UML. Oh, hot flashes…

Fast forward a shorter period of time and the web was born. Pages were static because HTML was designed to display text and when Al Gore invented the internet it was to share data. Keep THAT in mind and wonder how it has become what it has become (hint: people thought of ways to capitalize on it).

Now we have Content Management Systems. Notepad is one. If you typed fast enough and were a good enough coder, it would likely be the best of them all. There are many others. How does technology (in the web phase now but I believe moving towards the data phase) mirror nature? What is the best way to go about building something in technology that takes advantage of the myriad of lessons Nature has taught and that we have seen in nature?

By being flexible, utilizing highly portable and open formats like XML and XSLT, using an open API schema, and by delivering a framework of fatty acids instead of iron soap bubbles that become useless as soon as we touch them except in that we can charge to build them again with some Palmolive, we can make virtually anything we want as long as that framework does not prevent or straightjacket against it. That is the main problem with Content Management Systems and other Applications: people belong to their tools instead of the tools belonging to the people. You have seen organizations change the way they work because of the software the company purchased and the result be unremarkable. I am sure you have.

Way back when I was a developer, this stuff was getting lots of traction. PowerBuilder rocked the DataWindow (does it exist anymore?)  and the ability to deliver a query result in your screen – something pretty remarkable at the time – was enough to make people notice. We used them everywhere. We believed and knew how cool they were, but none of the Clients we showed our Systems to knew how cool they were. Do a demo of your product and just show the UI, pointing and clicking through a transaction. How frustrating is it to not talk about all the cool stuff going on behind the scenes? I hope it is frustrating. If it is not, you are only waiting to be replaced by a robot.

The obvious issue: there is no money in not having a Client tied to you. The obvious response: the money will come along with a bevy or other benefits if the relationship is sound. Worry about relationships more than deals. Worry about laying the groundwork and knowing when to get your biased self out of the way so people can fit the software to their needs.

I have to buy custom clothes because most of you are so small and satisfied with the ordinary or whatever is “in”. If everyone had to buy custom, I guarantee it would not cost me $300 for a pair of plain old slacks. It is a matter of necessity. What is a guy with 23 inch biceps who stands 5’9″ and weighs 310 pounds to do? I’ll tell you.

I pick a fabric. I get to pick. My shirt.

I pick a button style. My choice. My shirt.

I can go the bespoke route very easily. My shirt.

I get something just for me. My shirt.

Tailored. And I am the unlucky one? Financially I am, but that initial cost is immediately blown away by the fact that I do not look like I have sausages for arms and can actually breathe despite having a 23.5 inch neck. I can look damn slick. You cannot hope to look as slick as I do when you buy off the rack.

In the interest of transparency, all my custom clothes are ruined because I keep growing. This does not happen to normal people. Their custom stuff will look awesome for a long time. I am a monster. A freak of nature. You would not like me when I am angry!!

Custom is a framework. Off the rack is Out of the Box (and the racks themselves happen to be adjustable). With Custom, you can do anything. With Out of the Box, you do what is handed to you even if you have to change the way you do things and if changes are required, you essentially and many times have to start all over. I get free alterations for life. Micelles keep trapping the objects that make up this thing we call the Universe, or Nature, while nature defeats our best attempts to codify and predict it’s behavior.

So what is next? Visual development tools on top of flexibility layered with the ability to hook and link where required is there in frameworks. Some Content Management Systems are frameworks. Many are simply other frameworks with a face. XML is a framework. The difference is that a CMS framework delivers a framework at the inception of a feature instead of the inception of data (while in reality, it does both but people do not generally equate value with an XSLT definition). There is none. Until it manifests. It does not exist until it manifests. It does not matter until it manifests except to explicitly NOT do what you imagine it to, but what it is capable of. Usually, that is more than you hoped for or, you learn quickly that it was a dumb idea and save time and money. Soap bubbles cant fly you to Tahiti.

Do you see the pattern here? Get to the point where you are just about to make a decision you cannot undo (often, this is building that sexy feature out of the box) and stop. Of course, you have to pick a direction, and you want to make judgement calls as to your feature set, but let the tailor do the tailoring. Don’t try to buy me clothes. We will both only look dumb within a short period of time.

From the micelles to the user stories and backlog to the Object Oriented tool to Agile Documentation it is about taking the smallest piece of something you know of which points towards or makes possible the manifestation of that feature, life form, or in reality simply gives rise to possibility. Nothing is possible without Possibility. With a Framework that demands little, allows for a lot, and is wide open to what is around it, Anything is possible.

What are classically the hardest pieces of an IT project besides integration and data migration? Here again we see the issue of two things requiring a third specialized object to provide enablement. In the case of integration, an API or WS or simple SDK at times will provide that enablement and that is ALL that they do. In and of themselves they look like stubs, or little hands looking for another hand to shake. Once you shake it – Shazam! That is what it was there for (cue the lightning bolts and theme song).

In data migration, you need data transformation or a procedure that any MS Partner would love to sell you BizTalk for even though BizTalk is not at all required. Those procedures will just sit there until they are fed data and then SHAZAM (lightning bolts) “I have the power!!!”

Just like I can take two sticks and rub them together, there are undiscovered directions that the objects we built will take. Millions of idiotic (it is my blog so I can say it) people are injecting fish venom in their eyelids to look younger. Dummy, please! But it is their right and they are mighty thankful that botox is available to them even if it is being used in something about as opposite as it was intended for as you can get. Fact is, it can be used for a multiplicity of things. Intent is not always as it appears.

If you take offense because I make fun of the way you look, just look at me. ‘Nuff said. It is a joke. Get over it, please. Bless you and your Botox. Shoot it in your toes for all I care.

Oh by the way, you know that you get a fire if you rub two sticks together? Plain old sticks like Dog plays with. They can’t be wet but eventually they will at least let off a tendril of smoke. I cannot speak to your forearm strength unless you are a developer (haha, cheap joke).

The smallest effective piece has the most potential.

Hmm… where do I remember this from?

Dagnabbit, Legos. It was Legos.

Phospholipids, Micelles, Liposomes, giant gap in history, development of iterative attempts (Agile), OO Toolkits, web frameworks – what comes next? I know what I think. Semantic Web, data talking to data, raw ontologies and Triples ( modus polens and tolens are awesomely pure and telling) laid out there in the world as something constructed like RDFa and able to learn. Yep. Learning machines. And as I said earlier on, a robot is going to take your job and you will be glad for it because this is not Science Fiction. I hate Science Fiction. This is reality and you can just bean a robot a few times with some bricks and it will pretty much shut down. Or, a bucket of water. That worked on TV. Or if the robots really become dangerous we can live in a submarine and plug our brains into things that let us learn at the speed of light and fight off the Evildoers in the Matrix.

For those who are a little less mentally slick, that was a joke. I have to say that, because there will a single nincompoop who cries that I believe in the Matrix. And thank goodness for free radical abnormalities like that. It is what caused the fatty acid to fold along with the fact that nobody said fatty acids cannot fold. And then the micelles. Then liposomes. Then all the way to Agility, OO Development, and platform based architectures and exposed APIs, XML, and simple touchpoints that make lightning bolts come raining down in furious realization of potential, as though uncovering the Ark of the Covenant, as though evolving as a species or as Nature, right in front of our eyes.

Say no to that which limits. Say yes to that which makes possible and allows. Keep your goal in mind, do not trust anyone who has not earned it, and you will be a smart human being who at the very least is known to read a kickass blog.

Let me know how I can help. Seriously. I do not charge money to be a human being who cares. If you want to hire me, we are talking big bucks because right now I am seeing what it is like to be plain old Josh without assumption or constraint.

Trouble is, there are always constraints and my battle to constantly evade them is proving futile (see disclaimer).

Best Regards,

Josh Milane

It has been expressed to me that I may want to point out that much of what I write is property of MiT Consultants, LLC and only expresses the opinions of Josh Milane, but I do tell the truth and I will not lie to you. I do all this in memory of my Father. You got beef?

“Unlike other memory applications, Smart.fm takes a social approach, letting users share their lists and add comments to other lists. And in the future, Lewis says, there will be more ways to pull information into the system. The company is working on integrating with Freebase, a site that collects user-generated databases. Once the effort is complete, Smart.fm users who are interested in a particular topic should be able to access information about it from Freebase automatically.”

via Technology Review: An App so You’ll Never Forget.

Look into this. The tiny quote I pulled doesn’t scratch the surface of what is really going on here. The implications are obvious and stunningly powerful. While it is not quite like sitting in the chair on the Matrix and getting Kung Fu downloaded directly into your head, the fact that smart.fm has partnered with Freebase is wicked cool, and for some reason (I should probably figure out what this reason is before I post this, but I am in kind of a rush) I think this will be good for the Berners-Lee Semantic Web (as opposed to the Google Semantic Web). Psyched.

Josh

Social Networking is functionality regarding data about people.

Data is as data does.

What you do with that data is what matters, eh?

So what is Google doing with the data that they are capturing data in support of the Semantic Web? I am sure they will not tell me, but I still wonder, and still do not trust them.

Right now, there is an old “supervisor” of mine shaking his little head at that last comment.

And he is probably still using Chrome like the other cool kids. I wish I was a cool kid.

Best,

Josh

Still, in the process of communicating what is on my mind, some people may be offended and I only ask that you understand I am one of you and if I ever stop asking questions – even about those things I think I know inside and out, I should be slapped around (lightly, please).

So, this morning I stumbled down the hall, aching as usual, like a bear with arthritis, and Flip This House or something just like it was on the television. I rarely watch TV, but the channel was already on, my wrist hurt, I did not know where the clicker was, and I got sucked in. Very quickly, the Construction Project Manager said  that he needed to visit the house that they were going to “flip” to define his scope of work.

I am thinking that the next time I work on a refactoring project, I will call it “Flipping this Software”.

As much as I had to offer an apology to IT PMs and Developers, I have to apologize to my Father as well. He owned a construction company for 20 years and built it into a nice success through blood and broken bones. This “realization” is a little embarrassing to me but I am glad that my Dad doesn’t use the computer except to look at pictures of cars and stuff like that. Anyhow, I worked for his sprinkler fitting company from about the ages of 11 to 21. I was Manager at one point, towards the end, when we closed to company due to reasons that are not appropriate to address here and would launch a tirade of who knows what nonsense I would spew about life at that point. The company closed as I was graduating college with a Philosophy degree, before my abrupt transition to IT, and I think Dad’s making such a big deal out of me getting a Colgate degree and not having to break my back every day resounded within me as profound. Indeed, the effort and gesture surely was. Somehow, it made me think I was doing something *entirely* different than he did. Until this morning, that seemed largely the case except for things like how to deal with Clients and other soft skills where he could still teach me a lot and where we now see eye to eye.

There seemed to be two kinds of projects; there were projects where you went home covered in dirt and grease and there were projects where you went home with a sore ear from your headset and sore fingers from typing. One was low tech and one was high tech – as though “tech” was a measuring stick of some sort. I am feeling a little dumb right now. On the plus side, I think my CV has to say that I have 15 years of PM experience and 12 years of IT PM experience now.

I remember few things from when I was young, but one of the things I remember was waking up at 4:20 in the morning and meeting the rest of the crew at the shop. The shop was where we did fabrication, preparation, loaded the trucks, and talked about how yesterday went, what was going on today (as well as who was going to do it), and what we were running out of in terms of supplies, what permits we didn’t have, or what other things were impeding progress. There were buckets we could have sat on, but no chairs, and still everyone stood without being told that there was a reason to stand.

This should start to sound familiar.

In construction, there is no talk of Scrum or XP. Someone might say, “huddle up!” or “get your @sses over here!” but stand-up /scrum was not in the vernacular. We had stand-up meetings every morning. How else will they know what’s going on? And more often than not, people work together on the same feature (hanging a 15′ 10″ pipe 30″ in the air takes more than one person, trust me and my compression fractures) and people need to know what is going on so they know what they can do or can’t do or might want to think about doing.

Also, people who were hungover and didn’t make that meeting did not last long. Dad was tough like that. I rode in with him so I couldn’t be late, even if I wanted to… and I DID want to.

The argument I have heard, among others, is that software development is not widget manufacturing. This is true, but widget manufacturing is not software development either. Let’s look at this a bit. Gather ‘roud.

Each process involves tasks, people, and steps (yes – budget, scope, time, cost, customer satisfaction, etc., etc., et cetera too). The kicker – the x factor – is always the unexpected, and Agile “expects the unexpected” as opposed to it’s mortal enemy: The Waterfall Method. As we should say in the shop (because we talked this way), “shit happens”. Things fell on your head. The Inspector was a stickler. The carpet crew came in a week early. Whatever. Dad didn’t want to hear about what the problem was as much as he wanted to figure out how to fix it or to make people aware of it and incorporate problem solving into the process of construction (oddly, the phase of MSF where you code is called Construction, but maybe it is not all that odd). ScrumMasters are trained (hopefully) to do this, but in other industries, where the deliverable is something you feel and see, it is perhaps a much more obvious question because (and I am sure there are other reasons as well) it is not something you can let slide, even for a day. You can’t just walk away and assume it will resolve itself and hope/assume a specialist of some sort will handle it because it *will* be brought up the next day and some ambiguous excuse like “it just takes longer than we thought… I need more time” won’t fly. I am not saying that a poor excuse will fly in software development, but because it is a more amorphous process, I have seen it accepted at face value and passed over much more often than I have seen it glossed over in construction. Screwing in a pipe fitting is a simpler process than coding a web service, but there is a lot more involved than the actual performance of a task. Try coding a web service with the keyboard over your head, on a 18′ ladder, with greasy boots and people running around like crazy with heavy equipment and sharp things that can cut you underneath.

Software development is not harder than manual labor. It may be more cerebral, but hey, you made that choice; you chose to work your mind harder than your body. You need to live with it and be accountable, responsible, and professional.I have my scars from working with pipe, and I have scars from software too. Most cause me to write. They aren’t as cool to the chicks, as they say.

Expect the unexpected. Be Agile and adaptable. This makes sense to my readers when it comes to building software. For a great example of how this holds true in other vacations, please read this account of a software professional building a fort. All the examples I could give of the unexpected happening, or of dependencies changing form, requirements shifting, and the like are there. Still, I think the following is interesting, which means I force you to read it if you want to read this top to bottom:

• While I worked with pipe and grease and smart people with largely non-formal education:
  • Scrums happened every morning because it was required. What needed to go on the truck? What happened with that standpipe yesterday? Did the ceiling guys come? Did the fabrication shop drop off the pipe this morning at the job site? Etc., etc., and et cetera.
  • XP happened every time there was >1 humans required to accomplish the task effectively. Try having two people hammer a nail… it is like XP in a lot of places I have seen XP explored. IMHO. This is not to say that it is always a total and complete utter waste of time when you have competant people. Not at all.
  • Lean Principles were mandated. Waste? Forget about it. If we had a 12′ piece of scrap in the back and could cut a foot off of it, thread it, and use it, that was one less giant piece of metal in the shop and it only made “duh” sense. Waste was visible, and smelled a lot of the time. It was physically dangerous, too. And there was no way in hell I was going to drag the stuff to drop 50 sprinkler heads to the site before it was needed unless it involved no overhead or risk.
  • The Waterfall approach was understood to be “sunny day” at best, and was a good thing to think about at project onset, but only to see where it wouldn’t work or be dependable. Even most of the strict Agilists will admit that before you start coding, you need a User Story of some sort.

The methodology that reigned was “what makes sense for this project?” Implied was these conditions, these circumstances, with this stuff going on simultaneously, with this person out sick, etc., etc., et cetera. Every job was custom, although the good old toolbox was always nearby (see previous metaphors about toolboxes for yet another metaphor/pun).

There is no way someone could walk out of school, even (especially?) with an MBA and be an effective construction project manager. And we were a subcontractor. We had our challenges and the General Contractor got to inherit them, or us, in addition to his/her own: OSHA coming (watch everyone run for their hardhats), budget cuts, etc., etc., et cetera.

So my major beef is that we have Agilists and the like bickering back and forth about how novel their approach is while we have others saying that it (agile development) has been around 15 whole years. Neither is true. It has been around for a long time. Software development in OO enterprises has not been around a long time. People are funny. They will find a way to adapt to new challenges. People are agile. It is not that these people bother me in their declarations of novelty, but more so in the fact that they seem to have ad hoc eliminated the possibility from learning from other disciplines, with Toyota being the most notable exception. Maybe the cool Japanese words like muda make papers on Agile seem almost enlightened and Eastern. I don’t know. Maybe success speaks to everyone. I don’t know. Both postulations probably hold some water. I like the idea of people selling a process as an aincent art by using an exotic work much like I like the absurdity of people who have Chinese characters framed in their house without knowing what they mean for sure. (I always kind of hope they really mean “Whomever hangs this is an @sshole”). 

“Interesting painting you have there… or, I guess that’s a word or a letter or something?”

“Yes, that means ‘peace’.”

“Ah. Peace. Nice. So it’s framed, and in Chinese instead of English, why?”

“Well, there was a space there on the wall, and me and Mrs. Simmons have strong dislike for muda.”

(No offense to those of you with Chinese character tattoos. That was a smart move. No, really. Looks exotic and edgy, just like the tribal band around your arm.)

Seems it isn’t enough to have something smart or good. You have to be fashionable and have a cool name, decoration, or what have you. Read about the success of  Yellow Tail wine for more on that. Don’t get into the Six Sigma Blue Ocean theory. It’s theory.

We are all on the same page. We are just looking at it from different angles, which is GOOD. But now, let’s look at more than that one page and try to gain some perspective? I understand about the productization of methodologies. I really do. I can’t say I do not hope my book does not sell like crazy. Still, you gotta be in this because you love it. If you love it, and even if it is a love/hate relationship like mine, you involve more than your brain. Your heart is tugged, and you go home wishing you had done something better even on your best day. I would like to see more of that. Honest work towards refining the process of developing software will make the world a better place. More focus on Semantic Web technologies will make the world a better place.

And you will make a pretty good living if you work at it, I think. Especially if you are talented and ask the tough questions, learn the hard lessons, can offer calloused hands to the effort. I have nothing against smooth hands. I just don’t want my carpenter to have them. I lift weights, so I have hands like an elephant’s heel, if they have heels.

Additional Questions:

• How is developing custom software for an unsure Client truly different than being an interior designer for the stars, or a wedding dress designer for a new bride? Besides coding. Don’t be a wiseguy, please. Leave that to me, unless you’re really funny.
• How is doing iterative development for a large and sexy Client (using RIP, for instance) truly different from a home architect working with a wealthy and irritable dot com couple circa 1999?
• You get the idea.

Thank you for reading. Meanwhile, please try not to muda any Yellow Tail.

Josh Milane

The Horizon Report

From the document:

The Horizon Report is produced each fall using a carefully constructed process that is informed by both primary and secondary research. Nearly a hundred technologies, as well as dozens of meaningful trends and challenges are examined for possible inclusion in the report each year; an internationally renowned Advisory Board examines each topic in progressively more detail, reducing the set until the final listing of technologies, trends, and challenges is selected. The entire process takes place online and is fully documented at horizon.nmc.org/wiki.

I like it because this notion of “Web 2.0″ starts to look kinda silly when Semantic technologies and Smart Objects come into the picture. Sure, this is a report about what may be, one day, reality. We can Twitter all day right now, as I write this.

Er, yeah.

Speaking of 2.0 and social whatnot, this is pretty interesting if you are curious about real data as it refers to social web apps and their usage.

Best,

Josh

I have previously written on the subject of Requirements Documentation, and I have had to fend off the Requirements groupies with a stick. They come in droves, at my door, throwing clothing at me and asking for autographs. It is only natural; I understand the universal sexiness of Functional and especially System requirements. My thoughts change as rapidly as the New England weather forecast, but there tends to be a thread of reason that follows.

So here is another post regarding requirements. First off, it makes sense to once again reiterate the common method of codifying requirements: MoSCoW. This link is not to Wikipedia, but it is to a post written my someone who puts PMP after their name, so beware.

Must Have items are items that, if not delivered, will make the effort a failure.

Should Have items are items that should be delivered unless they have a significant (negative) impact on the project.

Hang in there.

Could Have items are items that should be included if it is more or less, easy to do so.

Wont Have items are items that will be omitted from scope for the time being. In practice, the VP with a great idea is told that Wont have means “it will be in the next release because it really is a fantastic idea.”

Now, looking at those four flavors of requirements, which is actually required? Only one. Only the Must Haves are actually required. The others are ancilliary topics that fall into the Requirements Bucket because they are possibly going to find their way into the scope. They are really possible scope items, not requirements. At least, not yet.

This is a given, and no great insight. However, in writing RFPs or System specifications, I see people struggle with codifying their requirements. There is always someone who will say Requirement X is a Must Have because they need it, but the question is, does the System need it? Do the stakeholders need it? Does this effort, in hand, being executed and scoped, require the delivery of that item in order to be considered complete? This is a larger question and point towards what Requirements Definition really is; it is really project definition. Once you define a project, you can start work on it. This is breathing the first breath of life into something that you hope will start talking to you.

They say that the final scope is the codebase. This is true, but it is also a bit cutsey for me. The final scope is never met, because the System is never something that is placed on a shelf and considered “done”. The scope may be delivered, but that does not mean much in the larger sense. I am sure you have had a Client who signed off on requirements and was unsatisfied with what they got, despite. Well, I have. A long time ago, of course…

There is the concept of progressive elaboration or iterative refinement, but the classic PM Methodologies would have these ideas exist as transient entities that cease to exist upon project closure and documentation of the famous Lessons Learned. There is no final scope. There is only the current scope, and at times we might refer to that current scope as finalized, but in reality all we have is the product or project at a point where parties have decided that it is complete. Some times, it is considered complete because of budgetary constraints. Does this mean it is really complete, or that it is good enough for now? What is the difference? There is one. As always, you want to exceed expectations. For me, for instance, as long as I shave one day during the weekend, my wife is thrilled. In those cases, I have exceeded her expectations. We set the bar kind of low for me on the weekends, especially in the morning.

Some of the features or functionality present in that completed scope/project/product will not be listed as Must Haves. However, they were. Without them, the final scope would not be realized. There are dependencies, obviations, hallelujah moments, and other moments of serendipity that occur as you develop. This seems like semantics, but it is not. There needs to be life within the MoSCoW classification schema, and we need to allow for agility. As much as you are stating that X is a MUST HAVE, you have to understand that this may imply something else is a MUST HAVE BEFORE THAT, or a cant have after that. You get the idea.

Of course, much of the Big Up Front Requirements (please check out that site – Ambler is great to read and to make you feel like you know nothing) school of thought is fading and small teams of relatively informal developers are making remarkable things happen with only Story Cards and a burndown list. Nevertheless, in creating priorities for the agile framework, some sort of codification is useful. MoSCoW may be your codification of choice. You may, alternatively, number each 1-5 with 1 being most important and 5 being relatively unimportant. There are ways to represent just about anything, visually. It does not matter, in my opinion, which route you choose because the fact is, new items will find their way into your project and all you can rightfully hope for is a solid and informed starting point. Building software is not manufacturing widgets. I have been all over that topic, too.

What is required is an understanding that scope and functional and system behavior or characteristics is something that will breathe on it’s own if you start it on life support. You have to artificially get it up and running, and it will tell you what it needs, what it can do without, what falls away naturally, and what was forgotten and cost someone their job.

Here is what I suggest:

Write requirements in a declarative, positive fashion. Just like the old books say to do. State that the System SHALL do X if only because it is one of the rare times you can use the word “shall” without seeming pompous. Requirements ARE pompous. You are mandating. Each requirement shall be written in a way that removes ambiguity as to what the actual need is and is independantly testable upon delivery.

This brings up two other subjects: traceability and requirements that are more questions than requirements.

Regarding the latter, if you have a requirement such as “The Vendor shall describe what data export formats are supported by the reporting tools,” you really have a quesiton. There is nothing wrong with having both assertions (requirements) and requests for affirmation (questions) in an RFP. If the requirements document is detailing a product, these questions should be fleshed out with the team and answered before being documented as requirements. Simple enough. The Product Owner needs to step up sometimes.

Regarding traceability, this is something that I think goes overlooked far too often. Every requirement should have an associated identifier. Say, “1.2.4″ is your requirement identification. There is tremendous value in that number. First off, do not change it once the document is finalized. Secondly, it is telling to see a traceability matrix that shows how requirements are mapped to user stories or use cases, to development tasks, to test cases, and User Acceptance Testing (UAT). Yes, there will be changes along the way, but this will obviate where those changes occured. “Hey, what happened to 1.2.4? Oh, the Client decided that they didn’t want to export their data after all? Where is that documented?” It should be documented.

There are those who say the cost of maintaining traceability documentation and traceability is too high. These people, like Cockburn, who I cannot argue with and who’s fascination with fully-dressed Use Cases scares me quite thoroughly, can even quote studies:

On one project (corporate IT context), we deliberately studied the cost for both installing a traceability tool, and the human labor involved in keeping the information up to date. The cost was so staggeringly high that the client removed the traceability requirement from the contract.

Even Ambler has his doubts about traceability matrices.

I still like them. I like them as light, non-threatening ways to see what was delivered as compared to what was envisioned. I do not, however, recommend allocating too much time towards maintaining a master document. The goal of these is to trace. Obviously. With agile project, this may prove impossible or far too difficult to maintain. That is why requirements, in my opnion, should not be written with the Big Up Front model in mind. They are a starting point, and they should be as accurate as possible, if you are writing them at all.

The fact is, I do not like requirements. I think they are largely a waste of time. I much prefer Context Diagrams, Role Maps, and User Stories along with iterative development and lots of Client interaction. But this post is about requirements, since people love them. Sometimes, however, you really need traceability. Large clients and government entities may mandate it. So, in those cases, we become less “agile”, more formal, and do what the project calls for. Keep in mind, there is often a happy medium and one does not necessarily exclude the other.

Tip: after conference calls, send your notes to everyone who was on the call or make them available on a Wiki. That way, any directives or changes that are made can be traced back to their origin.

• I am going to plug a product here. I use  for note-taking. I think it is fantastic, and I encourage you to download and use it instead of OneNote or whatever you use. It is one of the only pieces of software I have purchased in recent years, and I only bought it because the free version turned me on *that* much. It even has an IPhone app, and well, I think its just fantastic.

In short, use some type of requirements prioritization technique. I think you have to, if only to make order of madness. However, anticipate change. Build your requirements so they stand strong, alone, and are provable as true or false upon *conceptual* delivery. Things change… all the time.

All of these things mentioned in the previous paragraph are Nice to Haves. That should tell you something?

Best,

Josh Milane

From UML.org’s nice article on Visual Modeling:

UML has become the lingua franca of software development, allowing engineers to exchange their designs freely. Nowhere is this better illustrated than in the software for the new James Webb space telescope, scheduled for launch in 2013. To aid communication and help meet stringent reliability and performance goals, all the software being built for the telescope by NASA, the Canadian and European space agencies and all their subcontractors is being designed using UML.

Don’t even get me started about Model Driven Architecture. Its like the SemWeb… I want it to work. I really really do. I think a

I am sure that many of my readers have disappeared. More likely, they have just stopped checking in. I doubt any of you have spontaneously combusted, though it would be cool if you did. On video. No offense.

So here is my little nugget for the day: There is no such thing as Project Management.

Everyone has been duped. Duped into believing there is a “Body of Knowledge” or a “ScrumMaster” or any number of things related to IT project management. There is no Project Managment. There is task management. A project doesn’t keep changing – it remains amorphous from initiation through delivery. You have tasks, and you manage those, along with people, expectations, budget, and really everything besides the project. The project is just what people talk about in to have a common reference point. They can only directly talk about tasks, deadlines, and other empirical data/things. A project is a cloud without clear edges, and it moves, this way… then that. Sometimes it is by design, but sometimes it is not.

Ayer said if it cannot be proven true or false through experience, it is a nonsensical statement. I think considering a project anything more than a bucket of tasks, people, meetings, and assorted ceremony is nonsensical. You have your phases, milestones, meetings, UAT sessions in one for or another regardless of the underlying PLC, but what does this really mean? Project start, do, and end. There are things that people look to in order to recognize a given effort. People need to communicate to make that happen. Ultimately, the effort either passes the test, fails the test, or falls somewhere in between and there is an uncomfortable call where you and the Client try to determine what is fair. Wouldnt it be obvious?

An Agile SDLC removes the need for the “classic” PM and GANTT charts (thank God). However, a ScrumMaster is not enough (that’s another sham… pay $1200 and you get certified. No test, no obstacle course, just pay and get the stamp – and yet somehow, people eat it up). You need someone with common sense and communication skills who isn’t afraid to ask questions and is, above all else, good at finding answers and not emotionally attached to anything but (and this is not mandatory) the Process and Excellence. Why be emotionally attached to the Process? If you have to ask, I don’t think I can explain it to you. You either love delivering good working software or it’s a job. It can be both at times, but the passion is what makes you great. If you don’t want to be great at whatever your chosen discipline is, I don’t understand you, but know you are out there in vast numbers. Emotion is key in Project Management and Software Development. You have to care. You have to really give a damn. Day to day, decisions are made pragmatically, but that pragmatism is a tool leveraged by the passionate. Or at least, it should be, in my opinion.

Define features, assign priorities to them, practice RIP or RAD or just plain old iterations and while you do UAT, let the client prioritize and re-prioritize and add features all they want because in the end, it is their baby. You want it to be yours, and it might feel like yours, but you are babysitting. I dont know… maybe you are delivering. In my finer moments, I like to believe you are performing magic and manifesting chances for ephemeral excellence, otherwise lost in the mist (or something similarly eerie).

Project Management isn’t about deadlines. It is about delivery. There is a big difference – just like software isn’t made of activities, but it is made of features. Management becomes a means to an end and not a science unto itself beyond the fact that it must include an inherent ability to turn itself into something else. What is good for the goose might not be good for the gander. Still, we can try to lump them together for sake of expedience and to sell books on The Process. We impose things like deadlines and estimates to give the illusion of control. While deadlines and estimates can be marginally effective, they will never be as effective as passion for Process.

People point to Parkinson’s Law and claim that workers somehow manage to take all the time they can to fulfill a task.This is only rarely true. More often, people complete a task in as much time as required. It is simply the definition of what required means that can lead to varied results. Process is malleable. Process is not a set of phases and it is not a templated approach. It is different for each project, each organization, and it will possibly change mid-stream. Process is not pre-defined. It is defined as you go, like your System, and in the end, the code is the functional spec (the path you take is the Path). I have found it best to let the Project reveal it’s Process.

Some scupltor I should know the name of but don’t said that he simply removed the excess marble from the statue. I like that ida. Of course, you have to know how to recognize the signs that something is unclear, iterative, risky, costly, or otherwise noteworthy and be prepared to nudge it along and steer it. However, there can be no didactic System of Project Management. In fact, as I said earlier, there can be no true Project Management. There can only be work, workers, money, expectations, and the like. This is not a bad thing. Not at all. And I think the IT community is coming to realize that Project Managers cannot be certified but by experience.

“If you aren’t making mistakes, you’re not making enough decisions.”

I hope you are all well. Sorry I had to disable comments. I don’t like forcing people to register and to be honest, enough of you email me that I don’t see a need for comments.  I am quite happy to discuss, but that is because I like this stuff and want to learn something as often as possible. I do not use this blog to generate business, expressly. I use it to learn. It is, right now, part of my Process. You can say I am being very literal, but really… take a look at that GANTT chart from day 1 and compare it to the chart on day 100. Where is the project? In both, in between, and probably calling on the phone to find out when the mail merge feature is going to be ready because the bonus letters need to go out yesterday…

Best,

Josh