Philosophical Musings on Technology
Does your Org have an SDLC Coach?
Call them a coach, a mentor or even a SDLC therapist, but either way you need one.
Their role is to help improve the process and improve how people do their roles in the process.
In my private lexicon, I define these roles in the following unscientific way:
- Coach - on the sidelines and helping to call the plays. Swaps in the right people at different times
- Mentor - works in a one on one capacity with resources. May do as well as help others to do, in a hands on way.
- Therapist - somebody that sits with a resource and a/or a team and does sort of talk therapy. Things like a Sprint Retrospective are talk therapy sorts of activities.
I think you may not understand the value of a person or several persons (larger organizations)playing this role brings.
Thing they can do:
- Identify misunderstandings in the team members understand of the SDLC and their role
- Identify wasted efforts in the SDLC by seeing the day to day activities and asking resources for things they see as wasted effort
- Help resources to better manage their tasks and the quality of their work. Reduce the stress and unhappiness of a resource by being a cheerleader (maybe that's a fourth role)
- Help identify training needs for people on the team by seeing how the better performers do versus the lower performers doing the same tasks/activities.
- Help refine and optimize tthe SDLC as the org changes, project changes, team changes. As a team becomes better at a SDLC like Scrum, they no longer need "crutches" that they might have needed to begin with. They may need more sophisticated tools than they could initial handle
Now the big question:
WHERE DO I GET ONE OF THESE MENTOR-COACH-THERAPISTS?
I'll save that for another post 
Do you smell that? It's your requirements. They stink.
Why do they stink?
But we are an agile shop!
We use all the latest tools!
Are you sure they stink?
YES
If you are using words to document your requirements I can almost guarantee you they stink. The English language (and most other written textual languages) are filled with delightful ambiguity.
Ex: "One morning I shot an elephant in my pajamas. How he got in my pajamas I'll never know" - Groucho Marx.
Words are the enemy.
Compound sentences and run on sentences and conjunctions and punctuation and etc. are the enemy. (that is meant to be illustrative
The fact that English is basically one dimensional. You read from right to left and wrap around. It very hard to refer backwards in English to a previous sentence or phrase. You could draw arrows but then that's not English - that's power point!
Doing requirements in PPT is even WORSE!
Requirements actually only need a few kinds of sentences to be chock full of meaning.
They are:
- X is a type of Y
- X consists of B number of Z
- X is associated with C number of Qs
- X can do the following actions
- X can only be in one of the following states {a,b,c, ...}
- X transitions from state A to state B by action F
- <and a few others>
ALL of those words designed to NOT convey meaning without the READER implying the context for the meaning! ("kicking the can down the alley" in terms of clarity)
Then you try bulleted lists, numbered lists. That helps a little with hierarchical things but it gets pretty ugly.
An English has all those contradictory rules and meanings and context sensitive meanings and ...
Instead, I have found the use of a small subset of UML to be AMAZING at reducing the fluff, BS and "I thought I knew", "are we done?" types of situations.
YES THIS IS FULLY AGILE, Too!
Use these techniques in collaboration sessions between folks on the team to tease out the requirements in real time, on whiteboards, then take pics with your Android Phone, an actual digital camera, your Xoom tablet or even your iPhone / iPad / iDevice. (Or get one of these thingies http://www.acmimio.com/images/productimages/Xi_brochure.pdf)
Below is a simple model in UML that would take a page or more of words to describe and then probably not nearly as clearly.
A Person (entities/classes are in boxes) Is Composed Of (sub box of an entity of the lines drawn between):
- A Person Has A DOB That Is Of Type Date
- ...
- A Person Has 0 or 1 (Current) Legal Name //you might be born and not given a legal name until later
- A Person Has 0 or Many (Previous) Legal Name
- First Name that Is Of Type string
- Last that Is Of Type String
- A Title that Is Of Type Person Title That Is 0,1 or 2 of the following instances {Dr. Miss, Mr., Mrs. Rev.} (instances of a class are underlined)
- A
This the state chart (state model) for a person in the admission process for a university.
Each rounded box is a state.
Each arrow between is what action causes the transition between states.
A Student (Class) starts in the Lead state
A Student is then called by a recruiter and becomes Contacted.
A Student Submits and Application (Application Submitted) and becomes an Applicant
A Students Application Is Accepted and they become Accepted or A students Application is Rejected and they become Rejected.
A Student that is Rejected can Reapply and become an Applicant again
....
That is just a sampling of what well written requirements in UMl can do to provide clarity.
Also, because UML forces you to write simple, unambiguous statements, it helps identify questions and identify the answers to questions that you thought you knew.
Finally, though these diagrams were created in Sparx Enterprise Architect, you can do all of this on napkins, post it notes or whiteboards (that's actually how I usually start to avoid getting distracted by the tools.)
Contact us if you'd like to teach your teams to write requirements that don't stink.
Simon Logan Technology Partners
917 __ 783 __ 7477
You need a Business Domain Model. But, We don't have a Business Domain Model! (oh, yes you do ...)
Software implements the business domain model of whatever its used for. BY DEFINITION.
It may do it poorly or incoherently or inconsistently or incompletely or wrongly but it DOES implement it.
So you HAVE a model, its in the source code.
Its HARD to visualize it, though.
You NEED a Business Domain Model (BDM) in a way that you can easily reference it, update it, argue about it, ... but if its only in the code, how can you discuss it with the User? BAs? PM? ScrumMasters? Testers?
What happens when the BD (Business Domain) you build software for changes SO MUCH it no longer aligns with the BDM as implemented in the software? How would you know? (Hint: your customers will complain about your software, ask for changes or buy somebody else's product)
First, I define a BDM as an unambiguous (as much as possible) description of the things, behaviors, rules, constraints, changes over time, workflows, events and goals of any business WITHOUT any detail that involves software or computers (ex: banking has existed for 1000's of years before computers - model that stuff and you have the BDM. Education is the same.)
Often times an industry changes gradually over time but changes so much that the BDM is NOT really what it used to be. Example snail mail and email are similar but NOT the same BD by a long shot. Video rental store and Video Download are different BDs though they seem similar.
So, every time you migrate a system or create a new version you are discovering the same info about the BDM but NEVER creating it in a way that is easily reusable or viewable. Instead, you embed the info in the coed in the software. AGAIN and AGAIN and AGAIN. Inefficient and error prone. Tribal knowledge is often trapped in the heads of a few. Its hard to bring on new folks and ramp them up because the know acquisition curve is too steep. SOUND FAMILIAR?
Worst of all, you can't tell if new customers actually fit your existing business domains serviced, well or are so different the software is gonna irritate the heck out of them..
Software's embedded BDM misalignment with a customers real BD is the source of cost, risk, aggravation, delay, customer dissatisfaction and frustration.
Does BDM fix that ? Not everything but it does reduce a lot of it.
BDM uses UML and other unambiguous mechanisms for detailing thing, relationships, change over time, important events, etc. A word document that contains words / sentences is NOT unambiguous, so it AIN'T A BDM artifact!
Will you do Business Domain Modeling on the next project? NO.
But I did warn you
"To Sharepoint or not to Sharepoint (2010)?", that is the question or " time to drink the koolaid"
I have been leading project recently that is building both new products and migrating existing products (ASP.NET 2.x based) to Sharepoint 2010. But what surprises me is how many people in the effort, mostly at a management level, don't understand what that even means.
They think, "Ah, we make our stuff run in Sharepoint. Thats cool." Basically the "poke our web app thru an IFrame in SP and you're 'built on SP'" mindset. Problem is, thats not what their customers think when they say "Built on Sharepoint:."
SP is a bit like its own operating system (on top of another OS.) Its a framework and a toolset. Whats the difference? Your code calls a toolset. In a framework - IT CALLS YOU!
A framework, like sharepoint (or LifeRay / WebSphere Portal / Plumtree / SAP Portal / ...), defines the behaviors/properties/features you need to implement. In exchange, it gives you a LOT in return. Think of it like taking all the common stuff you write in 5 applications, extract it into a single place (the portal) and you just write the stuff thats new/different. less work but that means less control for you.
Why should customers care? because they can buy stuff from other companies than you and it will integrate with your stuff with little or no effort. Also, the customer can create stuff in the portal, like workflow, and integrate it with your stuff with little effort.
Your dev team needs to use the facilities Sharepoint offers BEFORE they just go build their own. Sometime that means bending/warping things to follow the Sharepoint view of the world. But if you don't your stuff won't fit in nicely and "play well with others."
So, if you are going to 'Sharepoint Enable', you need to "drink the koolaid," because its likely your customers already have (Microsoft markets these stuff heavily) or you risk looking like a Sharepoint Enabled Wannabe.
Agile Project Crimping AKA Agile Shanghai
I'm coining a phrase - "Agile Project Crimping" - stealing the best people from a project in flight to do a different project, under the guise of "Were Agile, right?" Syn. Agile Shanghai.
So many orgs think that people are stateless. That you can swap them between projects without any impact.
It seems especially to happen to orgs new to Agile / Scrum. A new Scrum project is cooking along and everything is working great. Tremendous productivity, like they've never seen before.
But theres this other project thats in trouble or just starting up.
So, what do they do?
STEAL FROM PETER TO PAY PAUL.
They quite nearly knock the smartest folks over the head, stuff them in a gunny sack and shanghai them onto the new project.
It works once or twice, sometimes but never in the long run and rarely in short run.
It has the following impacts:
- Velocity of existing project is now unreliable because you tampered with the team
- negatively affect team cohesion (assuming they liked the folks shanghaied)
- loss of tribal knowledge - the ones they steal are usually the best and brightest
- the original project is now likely to have a vacuum filled with with a newbie that needs to ramp up
- Newbies consume oxygen and precious people time to ramp up
- People you pull off the project get fatigued
- You are building a hero culture
- A sign that you don't truly grok agile concepts
Don't do it.
Don't be a Agile Crimp!
Don't do the ole' "Agile Shanghai."
So much of what you think is true ... isn't. Why understanding the history of computing is important.
Who invented the light bulb? Wrong.
Who invented the telephone? Wrong
Who invented the airplane? Wrong
Who invented the cotton gin? Right. How did he get right? Wrong.
Who invented the MP3 player? Wrong
Who invented the home video game? Wrong http://classicgames.about.com/od/classicvideogames101/p/MagnavoxOdyssey.htm
Who invented Pong? Wrong.
Who invented the mouse?
Who invented hypertext?
Who invented the world wide web?
The first web browser?
The first browser with images?
Steve Jobs created the MacIntosh computer? The Apple I computer?
Microsoft is evil? Well, not always. WWWViola and prior art.
Who invented the microprocessor?
The digital camera?
Why is a CD 700mb in size?
Why I use the term "suck" in blog posts?
Colleagues have suggested gentler, less "declasse'" terminology, might be better.
I could use the terms: "bad","ineffective","unusable","bug ridden","insufficient","poorly conceived",
"inefficient","inconsistent","bug rich","pile of detritus","abomination","affront to all that is good and true",...
I use "suck" because it has a certain level of emotion attached to it, without being profane
To me "suck" has both frustration and hope attached to it.
Software (or anything else) that I attach the adjective "suck" to tends to have the following qualities:
- grossly missing the mark (the DESPAIR factor)
- we thought it would be significantly better.
- we seem to have tried to do better
- we aren't proud of what we've built
- our competitors "seem" to being doing it much better then we
- we believe we could do MUCH better (the HOPE factor)
So there term "suck" carries with it despair and hope, effort and yet missing the mark, willingness to admit our shortcomings.
I struggle to find a more palatable term that carries that emotion and message.
"Significantly missing the expectations of customers, management, the team and the industry"
just doesn't resonant the same as:
"our stuff really sucks."
.
The hidden cost of software development tools or "if we have so many tools, why aren't we more productive?"
The obvious: tools have a license cost.
Not so obvious: The average/below average guys love evaluating new tools and adding them to the process (they seem to feel like they are accomplishing something.)
The smartest developers don't usually like new tools.
(they tend to build their own using scripting/GREP/LEX/YACC/SED/AWK/PowerShell/Bash/Pipes/Notepad/SQL/Black Magic)
Managers often love tools because they live in la la land where software is just a manufacturing process (not a creative thinking / invention process).
Thus, if you are digging a big hole, you need a big shovel. Digging a foundation for a skyscaper, you need a steam shovel (a bigger shovel).
Tools have a learning curve, a risk, a burden and slow you down before they speed you up.
Too many tools can KILL a project.
Microsoft Project is not a tool - it is a wormhole into an alternative universe
Analogy: if you were a carpenter and worked building houses, how many tools would you have in your tool box? In your pickup truck?
You'd limit it to the tools that you could carry.
You limit it to the tools that worked well and didn't break.
You throw out old/broken/unneeded/obsolete tools occasionally.
You balance the time needed to learn to use a laser guided robonailer and the productivity you'd get back AND the risk of burning a hole thru your foot with the laser.
You wouldn't spend days in the store looking at tools.
You ask other carpenters what they used.
You'd watch other carpenters and the tools they used.
(note: inference by analogy is dangerous but useful in this case.)
You need to think that way with the tools you introduce to your SDLC.
Answer these questions:
- Costs - initial, long term, getting OFF the tool
- Learning curve?
- What tools do I get rid of?
- Real benefits of the tool (not what the vendor says?)
- Risks of using this tool?
- Cost of evaluating the tool?
- What if I just use nothing?
- Vendor longevity - are they going to be out of business or absorbed by somebody - see: Java and Oracle
- Will the team actually use the tool?
Good rule of thumb: Let the developer decided what tools they want to use. Don't force tools on them.
I once did a eval on a agile backlog/features management tool.
We had Rally, Mingle, Jira/Greenhopper and a few others.
Rally seemed the most mature.
Mingle the slickest looking.
Jira the most ugly.
Developers tried each and chose Jira.
It worked the best for their workflow (and looked the worst).
They adopted it and used it.
Bonus: its licensing was also the cheapest.
We liked Greenhopper, the developers didn't - thought it was useless cutesiness.
It didn't get used.
Important to note: it also supported customization and the reporting needed by management.
We coupled it with old fashion whiteboards (low learning curve, robust, scalable, low TCO) and daily scrums.
Had the managers just made the decision we'd likely have chosen Mingle (coolest looking and most expensive, yet powerful.)
They selected and they used it, faithfully.
Why is your organization delivering software that sucks?
How do you define "crap?"
How do your customers define "crap?"
What are you testing?
When are you testing?
Why are you testing?
Who is doing the testing?
What are you measuring?
When are you measuring?
How do you interpret what the measurements are telling you?
Thats a few questions to start with. Many organizations I have worked with measure NOTHING until the product ships and customer reports the bugs. Thats analogous to designing and building a car and measuring NOTHING until a customer buys the car, drives it off the lot and the wheels fall off.
Other organization measure things but don't know what to do with the measurements. So, they have data but can't act on it. They feel really good that they have data and its presented in power point But the value of the measurements is zero.
But the value of the measurements is zero.Start simple - only measure things that you can interpret and act on.
Examples of a few things to measure:
- eLOC - effective lines of code in methods and in class
- CC - cyclomatic complexity
- parameters in a method signature - how many things get handed into a method
- ratio of comments to LOC written
- number of places that call a method (afferent coupling)
How do I use these?
None of them, in of of themselves tell you something is good or bad. They tell you where to do further research.
As a single measure they are good but not great indicators of trouble.
Examples
- CC>20 - usually means the methods pretty complex.
- Method eLOC > 70 - thats a lot of code in a method to get bug free and mantain
- method parameters > 6 - why so many things getting handed in? Oten indicates a not very OO design
- afferent coupling > 15 - lots of things in the code depend on this thing being bug free - better write good unit tests against this method, especially. Maybe the code is too coupled to this, take a look at the design.
But look at the code over all and get a distribution to see if you have only a few high CC or eLOC methods or is the whole code base like this? the answer will tell you what you need to do next - fix the code or fix the team.
Use them combined together to find real trouble spots.
- Methods with high CC, high afferent coupling and LOW e:LOC may indicate poorly coded but really important methods.
- High eLOC with low CC usually means code that just doing copies from one field to another - take a look at your design, how OO is it?
- High CC and low ratio of comments is usually a bad sign. A complicated algo that nobody documented. Remember - commenting is more than documenting, its a mental check that the coder thought through the problem. As complexity of an algorithm goes up, likelihood of bugs goes up exponentially NOT linearly.
Track the trend over time:
- Watch how CC distribution changes from week to week to week. Watch for "knees" in the curve. This is the start of trouble. Catch it early.
- Watch eLOC - over time the amount of new code added should DECREASE at some point. Even shrink due to refactoring that removes redundant code and builds tighter code. If you are seeing it, you should ask why.
- Watch the size of the UNIT TESTS - a unit test that is >60 LOC is just as likely to have bugs as the actual product code. Buggy unit tests are a false sense of security.
Create a workflow process for metrics and manage the process as part of your SDLC:
- Design -> Code -> Measure -> Interpret Metrics-> Review Designs/Code identified in metrics —> Recommend Changes based on Reviews -> Implement Recommendations -> VERIFY recommendation were implemented
- Treat these refactorings like real requirements - backlog them, estimate impact,, schedule, execute
- Measure the efficacy of your process
Tips:
- Dont measure everything
- Don't measure what you can't act on - just adds noise
- A few consistent measurements repeated and tracked a better than a "firehose" of metrics
- Use tools
- Metrics data will create a data warehouse cube of data - think of it like that ahead of time - excel isn't enough of a tool to handle it
Proximity triggered phone app loading/unloading in Meat Space (physicalworld)
Since the portable handheld computing and communications device (AKA the phone) is becoming the defacto ubiquitous interface to the world, we need apps that are installed /deinstalled automatically based on proximity to a physical location.
So, you walk into Target store and the store's apps auto load. When u leave they unload. Like when you visit a web site it loads in your browser. Instead, when you visit a physical URL AKA a store / house / park / beach / zoo / gravesite / grand canyon the appropriate, sandboxed, context aware app loads.
If this hasn't been patented yet, i claim patent pending on the idea.
Think how cool it would be if you wandered up to somebodies grave site marker and your phone started showing a film clip of their life? or an interactive app that you could see different details about them? or like a new version of the hall of presidents, a virtual, simulated, AI based avatar of them you could nteract with, as tho they weren't dead? Cool and creepy, all at the same time.
If it was a retail store, you could give store navigation, special offers, research tools, gift suggestions, ... yeah, that might just be annoying but then again.
At the museum or zoo ... you get the idea.
Or how about in schools / universities. You enter a classroom and BANG the apps for that class period install.
So, who wants to build this with me (meaning who wants to fund it?)
Contact me and lets get it going!