Philosophical Musings on Technology

Does your Org have an SDLC Coach?

Logan Poelman — Thu, 18 Aug 2011 14:15:55 GMT

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.

Logan Poelman — Tue, 12 Jul 2011 18:28:54 GMT

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>

But your BAs and Product Management folks use words like "leverage","collaborate with","utilize","influences","is related to", "bucket","group","syndicate", ...

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

LegalName (entity) Is Composed Of:

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.)

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 ...)

Logan Poelman — Tue, 29 Mar 2011 13:43:00 GMT

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"

Logan Poelman — Wed, 23 Feb 2011 15:56:00 GMT

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

Logan Poelman — Wed, 02 Feb 2011 21:34:00 GMT

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.

Logan Poelman — Fri, 03 Dec 2010 01:54:00 GMT

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?

Logan Poelman — Thu, 02 Dec 2010 16:17:00 GMT

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?"

Logan Poelman — Thu, 02 Dec 2010 16:11:00 GMT

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?

Logan Poelman — Wed, 01 Dec 2010 16:50:00 GMT

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.

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)

Logan Poelman — Wed, 01 Dec 2010 15:04:00 GMT

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!

Are you testing in the Dark? Getiing Whitebox and Blackbox worlds talking. Code Coverage Analysis ( CCA )

Logan Poelman — Wed, 05 May 2010 02:05:00 GMT

Testing in the dark

So you have a QA group. They test everything that you ship to customers. They even have some automation in their testing. They use Test Director or WinRunner or WebLoad or ... but customers are still complaining about defects. They don't want to take your next release because your releases are so riddled with defects, even when upgrades are FREE!

You have 5000 test cases written by Business Analysts or testers or managers or customers or ?

You have even automated your regression testing!

But you are still testing in the darkness, poking around in a dimly lit cave with a sharp stick.

Blackbox vs. Whitebox vs. Graybox

Simple definitions first:

Blackbox - you write the tests without knowing the internal code or data structures but just based on what you think the application should do. Test are written at a user goal level.

Advantage - tests reflect user goals. You don't test things the way you think the code should work because you don't have that. bias.

Disadvantage - you don't know how much of the underlying functionality actually get executed. Your test cases may be highly redundant and add little value with each added use case.

Whitebox - you know the internals of the code, so you can write tests that stress things in a more systematic / targeted way.

Advantage - You can beat on the parts that are most likely to fail or if they fail, will cause the most trouble. Things like developer unit tests are generally of this type. You also have a better insight for what parts of the application get tested , notice I said better not perfect or even accurate.

Disadvantage - takes developer level knowledge. Take discipline to write tests that aren't designed to easily pass but instead designed to see if the code can be broken (see Test Driven Development debate onm what to test / not test.) Not a full "vertical slice" of the app many times.

Greybox - A combo of both. Insight from the whitebox but user goal driven oriented tests.

Advantage - better quality of tests

Disadvantage - Who writes them?

Whats needed is a way for QA testers to write blackbox insightful types of tests.

Feedback and communication

Feedback and communication are essential to any adaptive process, to learning, to getting along well with the other kids in the sandbox and to software development, as well. Test Driven Development, Continuous Integration and XP/Scrum SDLC all understand and leverage the benefits of rapid, low latency feedback cycles. Ex:

Change your code

Check it in

CruiseControl builds it and runs J/NUnit against it

Your unit tests fail

It sends you an email saying “you broke the build.”

So, you quickly fix it before your team mates find out and make you buy the donuts for tomorrow.

QA and Development need that same feedback about what is getting tested and in a larger sense than just individual developer unit tests. This is where code coverage analysis (CCA) tools like: Code Validator, Purify, … can help.

If you run your unit test suit on your build server with a code coverage tool, you can have a baseline and track test coverage, over time, how much new code gets added and how much gets tested, even at the unit level.

This is GREAT feedback to Development Managers for when/where to intervene and make sure that developers are putting in the needed unit test writing effort.

This is GREAT feedback to the QA Manager about what to do in the QA testing efforts.

Example CCA Reporting:

This is a CCA report on a project I worked on recently developing a MIDI hardware/software device. This shows the overall testing coverage in terms of number of files, lines of code, lines tested. (the tool is Code Validator from www.softwareverify.com one of several good tools out there.)

Even better than the aggregate statistics, this tool can tell you the specific files that were/weren't tested and by how much.

This shows individual files and testing coverage amount.

Whats a really nice blackbox to whitebox transition feature of these tools, is the ability to click the file name listed and see the code along with info on what parts did/did not get executed.

This show what code was executed (pale yellow) and what wasn't (pink) in any of the tests!

The ability to see what areas you are NOT covered in your testing allows you, with the help of the developers, generally to fashion either new QA tests that will execute that code path or add to the unit test(s) or both.

You can see what parts of the app you are never even testing before you ship your product!

Too Much Code Coverage

Yes, there is too much of a good thing. When you first do CCA on an existing project you may be "shocked, shocked!" at how little testing you are actually doing. This can be depressing and also trigger over reaction on the part of management. Pronouncements like "We must have 100% code coverage of all our tests!" are often heard in reaction to the first CCA reports.

But 100% isn't always whats needed (rarely and arguably impossible for most software).

In fact, sometimes, you are just going to live with NOT testing parts/paths of your code. Why? You can test every code path. It rapidly become TOO expensive, but different types of software in different market segments define "too much" differently.

But by baselining it and seeing what you have first, then adding tests and seeing the extra effort, then getting a coverage report after adding tests, you can make decisions about what level of testing you need/can afford.

Joining Code Coverage with Defect Reporting

An even more targeted approach is to take defects reported by customers, identifying how the developers fixed them and then running your test fixtures against the UNFIXED CODE to see if you tested the area with a defect in it. Depending on the answer, you will act differently.

If you tested it and the defect got through anyway, you need to change the test/add tests. If you didn't test that area, you need to add some tests.

Make changes and then run tests on the FIXED CODE and check the coverage to ensure that you test the area with the defect/fixed code, this time.

Code coverage analysis can help you to communicate between the blackbox and whitebox testing worlds in a targeted and actionable way. It can help add some science to the art of testing. Its time to come in out of the darkness.

"You can either light a candle or curse the darkness" - Ancient Chinese Proverb

You can't manage what you can't measure. Lies, Damn Lies and Code Quality Metrics. White box management.

Logan Poelman — Wed, 28 Apr 2010 02:50:00 GMT

Black Box Software Development Management

Imagine you are managing a group designing building heart lung machines for a medical equipment manufacturer. Wouldn't you:

define the features of the device

understand how it would be used, under what conditions, by what kind of users

design all the parts

review the designs

build a prototype

test the prototype

productize the prototype

ramp up the manufacturing process

build the parts (or outsource the manufacturing)

then MEASURE THE PARTS before assembling the whole unit?

assemble the unit and test its functioning?

stress test it?

Continuously improve the product

Continuously check that parts and the whole unit were being manufactured to specs and tolerances?

Are you doing the same with your software or are you instead doing "black box" software development management?

Where you aren't::

reviewing the designs - collaborative design and design reviews

testing the individual parts - unit tests

measuring the tolerances of the components - reviewing the unit tests, running metrics on the code base

testing the load capacity of the parts - stress testing the protoypes and the code AS ITS BEING DEVELOPED.

Code Metrics

Code metrics are great if you realize they are like a combination "metal detector"/"x ray machine" for code quality. They are tools that can help you detect things - they CAN'T TELL YOU HOW GOOD YOU CODE REALLY IS! They give you statistics. Statistics, as Mark Twain put it, "there are lies, damn lies and statistics."

The code metrics I find helpful include: (see http://www.ndepend.com/Metrics.aspx#MetricsOnApplication)

Cyclomatic Complexity (McCabe)

DIT (Depth of Inheritance Tree)

NOC (Number of Children)

eLOC (effective Lines of Code)

The way I believe you get the best value is by using them to find the overall trend in the code and find the outliers. Then, taking a look at the actual code that is in the set of outliers. DON'T BELIEVE THE TOOLS! Sometimes, the best way to implement something gives you bad code metrics! You need to review that code and make a judgement (or have your architects do it.)

Don't share the metrics with your offshore group / outsourcer / internal coders. Yes, I said DON'T share. Why? You don't want them to code to the metrics! They should code to the best implementation / design patterns / solution.

Use the tools to focus your code quality management efforts.

Measure it and you can manage it.

In a later blog I'll take about how to leverage those metrics, specifically.

Code Coverage Analysis (CCA)

So you have a QA department. But what exactly are they testing. Do you know what lines of code in your codebase get executed at all? Time to implement some code coverage analysis. Tools will let you monitor what lines get executed by what tests. Integrate that with your automated testing and continuous integration and you might have some idea of what you actually HAVEN'T tested when you ship.

Continuous Performance, Stress and Security Testing

Like continuous integration avoids "big bang" integration issues, these avoid "big bang" scalability, stress and security issues.

Start testing how the product scales as soon as the product can run at all. Don't wait. Start early.

Collect data over time. Watch the performance over time. It should slow down slowly. Then watch for when the performance drops precipitously. Back up and see what changes you just made. Its so much easier/cheaper to fix now then finding out you can't scale / handle stress / security issues 2 months from now (or 9 months from now, for that matter.)

So, stop managing in the dark. Come in to the light!

Copyright 2008-2011 Logan Poelman - Poelman & Associates, Inc.

Information Security, Home Invasion, Fox guarding the Chicken Coop, Who took all the nice pens out of the supply cabinet?

Logan Poelman — Mon, 12 Apr 2010 14:16:00 GMT

PODCAST is here

"A Bank of America worker who installed malicious software on his employer’s ATMs was able to siphon at least $200,000 from the hacked machines before he was caught, according to a plea agreement he entered with prosecutors last week.

Rodney Reed Caverly, 37, was a member of the bank’s IT staff when he installed the malware, which instructed the machines to dispense free cash without creating a record of the transaction. The Charlotte, North Carolina, man made fraudulent withdrawals over a seven-month period ending in October 2009, according to prosecutors, who’ve charged him with one count of computer fraud." - http://www.wired.com/threatlevel/2010/04/atm-hack/#ixzz0kzJLm3Fp

"Oh my Lord, they've hacked our bank's website! Harold, hide the silverware!"

When a corporation's website gets hacked, its a bit like a home invasion - its scary, its sensational, its fodder for the media, its exciting ... and its relatively low on the damage threshold, easy to detect, and a major distraction. But while everybody is worrying about the frontdoor hacks, that consultant you hired to migrate your database servers is installing rootkits and quietly siphoning off information without making much noise, at all.

When somebody steals through the front door we should be concerned but its the stuff leaving through the read door or loading dock, that often is more damaging / valuable / critical.

Corporate Espionage Does Happen

Remember who invented the telephone? It was Alexander Graham Bell, right?

" On 14 February 1876, Gray filed a patent caveat for a telephone on the very same day in 1876 as did Bell's lawyer. The water transmitterdescribed in Gray's caveat was strikingly similar to the experimental telephone transmitter tested by Bell on March 10, 1876, a fact which raised questions about whether Bell (who knew of Gray) was inspired by Gray's design or vice versa. Although Bell did not use Gray's water transmitter in later telephones, evidence suggests that Bell's lawyers may have obtained an unfair advantage over Gray.

...

Ten years after Bell's patent was issued, patent examiner Zenas Wilber admitted in a sworn affidavit that he had taken a $100 bribe from Bell, had taken a "loan" from Bell's patent attorney, and showed Bell the drawings in Gray's caveat.^[25]^[26] Bell responded with his own sworn affidavit that he had never paid any money to Wilber and Wilber did not show the drawings or any part of Gray's caveat to Bell.^[27] Bell testified that he visited Wilber before the patent was granted and asked Wilber what part of his application conflicted with Gray's caveat. Wilber told Bell that the conflict was with his use of variable resistance to cause undulating current and pointed to those words in Bell's application. Wilber suggested that Bell make several amendments to his application that eliminated the conflict and Bell complied.^[28] Examiner Wilber then approved Bell's patent which was issued on March 3, 1876. " - Elisha_Gray_and_Alexander_Bell_telephone_controversy

Did Bell steal the idea? Its still debatable. But, in one of the most influential products in the history of man, there is the possibility. Lots of smaller espionage incidents probably still occur but are a harder to detect.

Fox and Chickens and the Chicken Coop

If you bring in an outside consulting group to help with security or ANYTHING for that matter that could lead to a compromise, monitor what they are doing. Pair them with a buddy from inside your organization. Sounds expensive but saves lots of cash, in the long run.

If you hire somebody, you should do the same. There is a reason that in the movie "Red October," two guys had keys to launch the missiles and it took both turning their keys at the same time to do it - its much harder if you need help, to steal or compromise something valuable. Yet, you have DBAs who have complete, unfettered, unjournaled access to the servers. You don't let developers near the production servers because your afraid they'll do something stupid. Yet, you let DBAs and infrastructure folks "alone in the vault."

We have Police Departments and Building Codes for a Reason

I once had to help the CFO of a company save his 700 MB of "all my data for the last 6 years" in his outlook file, on a machine that wouldn't boot anymore with a hard drive that made a suspicious "rattling noise" when I removed it from the machine. I was able to get it to boot, one last time and quickly get a copy of all the data I could to another machine. It never successfully booted, ever again. The data was neither backed up nor encrypted. This was a company with 5000+ employees and yet the CFO was in charge of backing up and securing his data (Being his own Police and Building Inspector, I guess.)

Loss of data is sometimes just as damaging as theft of data. Do you have the executive management machines automatically backed up? Encrypted? Journaled? What about their admin's machines? (they often contain just as sensitive as documents as the CxO.)

BTW, have you carefully vetted the CxO's admin? If I were a hacker and wanted access to the most sensitive stuff, thats the job I'd want. Below the radar and yet open access. The admin could easily install a hardware logger, capture some stuff, remove the keylogger and nobody would suspect a thing.

I once worked for CxO that was so paranoid, he wouldn't let the IT guys work on his laptop without being present. He was paranoid of key loggers (and just paranoid in general, I think.) So, he watched over their sholders while they worked on his machine. He didn't however, encrypt his hard drive, so somebody could have stolen the laptop and gotten his data or removed the HD, installed in a different machine, booted, installed a keylogger, and returned the HD to his machine, if they wanted badly enough.

Why did he rob banks? 'cause thats where the money is!

Corporate Information Espionage is on the rise. Think you are immmune?

A little HYPOTHETICAL cautionary tale. Lets say you are a medical device manufacturer. You build things that get implanted in the body or devices that scan the body, you pick. Your company spent 20 man years developing the hardware and 10 man years developing the software, for it. I am your competitor. I hire somebody to steal your software. I know have removed months of time off my development cycle and you'll never know because the code will be sanitized and tweaked and hidden inside my device.

Would you even know?

Are you using an offsite firm or offste developers to design / write code? How do you know its not leaving by the back door of India / Ukraine / Buenos Aires / Cedar Rapids / Manhattan? I once worked on a project setting up an offshore "clean room" development organization, in India, for a Wall Street firm. Developers had only a screen, keyboard and mouse. They had no internet access (only a VPN to a segmented corporate network.) They had no email, flashdrive, CD burners, floppy drives, etc. All machines were racked in a locked cage only we had access to. Servers were virtualized to prevent leakage. No phones allowed, no cameras, no laptops, no purses, ... We segmented the teams up so that no team had complete access to all the source code, designs or data. Its hard but it can be done, when warranted.

Lock the doors and leave the back window open?

When I lived in Chicago in Hyde Park, we had a nice brownstone with a 3" thick oak front door, we had bars on the basement windows, we had a security system, we had a 6' high stockade fence, we had really noisy wood floors on the first floor and yet we still were burglarized.

I bought the house and the security system didn't work, I didn't know that.. Didn't get around to replacing it. Then, one night, I left the rear window off the deck open. Somewhere around 1am, somebody came into the neighbors yard, climbed up on their deck, hopped over my fence to my deck and crawled in the window. They only visited the kitchen, pantry and dining room and made off with several thousand in stuff (five brand new pairs of shoes, in the boxes, on the kitchen island. Oh, my Kenneth Coles!)

They stole credit cards, phones, purses and used them to try and buy gas, for other people for cash, BTW, immediately after robbing us. The police had the records and recordings. Yet, nothing was ever recovered and nobody ever arrested.

The whole incident scared the wits out me and my family.

But, I was reminded of one several things:

Criminals are patient
Criminals are clever
The weakest link defines the real security of a system
Detection is to late, deterrence is important, too. (should of had a big dog.)
Your neighbors weak security can affect your vulnerability, too.

So, what does this have to do with info security?

Make sure you:

Audit the system (bought a house with a broken security system)
Don't leave things of value within easy reach (like 5 boxes of brand new shoes)
Assume you have been penetrated and consistently audit your systems
As you improve your security systems, criminals will improve their attacks!
Criminals go for the easiest target (they came into my neighbors backyard but robbed me)
Trust but verify (Should have checked the security system when I bought the place, should have checked all the windows before going to bed)
Don't assume the guy before you knew what he was doing (I was told the house had a security system - I assumed that meant it worked)

I once worked in a company that was so paranoid that I could NOT have a thumb drive or a CD burner on my computer!! I could though, insert a 8 gig flash drive into the PCMCIA slot. So much for leaving the back window wide open while watching the front door like a hawk. ( I of course never put any sensitive data on the flashdrive.) But, at that same institution, we did NOT encrypt the data on laptop hard drives. So, If someone's laptop were to get stolen, its and easy task to remove the hard drive and put it on a different PC, boot from a different HD and viola, I have access to all your data.

Let say I know of a HYPOTHETICAL Wall Street firm that had all their trade data and trade requests flowing over a messaging bus that was developed internally and had NO ACCESS SECURITY or Journaling OF ACCESS to it. All you needed to know how to do was write socket level code (in Java, C, C#, PERL, VB, ...) and know what the TCP Address / Ports were and you could have tapped into any data you wanted in the firm. They also did NOT have a separated / segmented desktop and production networks so any consultant or employee that could get onto the network could have tapped into this message bus and either listened, set traded or modified the trade flow, if they were smart enough.

Do you know where your children are? Do you know whats running on your servers?

When I grew up there was TV campaign "Do you know where your children are?" to remind parents that kids out late, unattended, get into trouble. I was doing a application review a while back and was reminded of that message.

We were looking at the traffic between tiers in a Data Center application and low and behold, we found a strange protocol "eMule" http://en.wikipedia.org/wiki/Emule I think it was. Just a few packets here and there, not a flood of traffic but it was strange. It was most disturbing because it was on the PRODUCTION DATABASE SERVER! Which, was behind 2 firewalls and 2 DMZs! EMule is a P2P file sharing protocol used mostly for MP3 piracy but you could always package up customer data in a file that looks like an MP3 and ship it out through this protocol. Who would ever suspect? Take the data on the end of a "Brittany Spears" tune like "Toxic" and who would ever find it, even if they detected the file sharing? Hmm, clever, very clever.

Do you know whats running on your production servers?

How about when you deploy them to the cloud?

Desperate housewives - People Cheat

When I taught at NYU I was shocked, shocked! that students might try and cheat in my classes! In my classes! (somebody else's, that I could understand but mine?)

Mind you, these were Computer Science MS and PhD level students, not 1st semester freshman!

I had heard of a scandal where students were using language translators (basically a computer with lots of memory) to store course info and then read it back during a test. Thats not what happened to me. I had several not so impressive incidents.

In one case, students just submitted another students source code as their own. After, of course, doing a search and replace of some of the words in the source code, Ah, how clever! But they didn't change the STRUCTURE of the code, including blank lines, indentation, loops, etc. So, it was easily detectable using some pattern matching software. Yet, when confronted, the students initially admitted it and then later tried to recant the cheating! All with the source code files displayed in front of them showing the structural identicalities (is that even a word?)!

When, they flunked my course and were put on probation. But, eventually graduated and are now in the IT work force. Hopefully they have mended their ways. But, what if they haven't and they work for you?

The second incident, which was far more, ... hmm "amusing" doesn't quite cut it ... "interesting" ... "confounding" maybe ... incident involved outsourcing. I actually had a student post on Sun's website for somebody to write his homework, in exchange for a fee. He put it out for bid! (Obviously he will end up running some Fortune 100 company someday) The Sun webmaster contacted me and pointed it out. The student didn't do anything to disguise that it was homework for my class, even listing the class title and website.

We were NOT able to reverse engineer the identity of the poster, though. I speculate that it was actually a prank being played on me by some cheeky students. Touché élèves intelligents.. (I'd like to think it was that vs. somebody actually being that brazen / desperate.)

But these are the people that might someday work for you.

Continuous Security Testing

In the agile community, the concept of continuous integration testing is pretty standard. Tools like CruiseControl make sure that you code builds every couple hours. It helps detect code that is diverging in the code base and avoids the "big bang" integration nightmare that was commonplace in the past.

But what about security? Should we wait till the last minute to see how secure and application's design and implementation is? Sadly, almost every organization does. Instead, we should set up automated security testing WHILE we are building the application. That way, we detect the issues early, fix them when its cheapest and reduce nasty surprises AFTER deployment to production.

Can your competitors read your code right from the server, over the internet?

Many new languages like Java, C# (or any JVM / CLR languages) can be reverse compiled, revealing readable source code from your compiled code. JavaScript can just be read (stolen), as is in the browser. Are your teams using obfuscation and minification routines before deploying the source code to production build processes?

What to do? What to do?

Calm down, "Chicken Little", the sky isn't falling, just yet. Here are a few starters:

Categorize the value of what you have and what its loss would impact. Focus on the most valuable and easiest to reuse, first. Including:

Customer Private Data

Customer Behavioral Data

Corporate Financial Data (great for beating the stock market if you can get it.)

Software / Firmware / Hardware Source Code and Compiled Code

Designs (CAD, Word Docs, Scans, ...)

Supplier pricing, Customer pricing (helpful in negotiating if you are a competitor.)

Sort things by highest impact

Figure out how easily attacked those things are

Figure out how you might detect an attack on those things. Could you detect it?

Check if your security systems (IPS, IDS, Logging) are even working (like my broken security system.)

Get a real vulnerability assessment (get two, from two different firms, compare the results.)

Vet your staff. Make sure that outside consultants don't get the master keys and don't get left all alone to wander around, getting it trouble. Monitor and journal what they do. Forensic evidence is often extremely valuable and knowing its being collected acts as a deterrent.

Virtualize OS images. Prevents rootkit installs in most cases.

Collect Forensic Evidence fore later - journal accesses, updates to systems software, data changes, etc.

Journal their accesses. Let them know (deterrence is always helpful)

Don't depend on security through obscurity.

Don't roll you own encryption algorithms, SSO, tamper proofing.

Consider rotating people to different parts of the business.

Set up some "honey pots" to detect if things are getting pilfered. This can include embedding traceable words or phrases or patterns in source code that can be searched for / scanned for later.

Do lots more, than just these things.

Lather, Rinse, Repeat. You should do this several times a year or what ever makes sense to you business.

I've been using an iPad since 2003!

Logan Poelman — Sat, 03 Apr 2010 17:02:00 GMT

OK, not THE iPad but various tablets including one that in many ways is remarkably like the iPad.

As far back as 2003/4 I used the Gateway Tablet PC (thanks to Tim Snyder the CTO at for funding that experiment.).

I used it to do shared whiteboard stuff over WebEx to 4 countries at the same time (US, France, India, Denmark) at one point

Good

Small size
Cool for demos, presentations
Presenting doc / stand

Bad

Battery life - 2 hours
Lose the pen and your are screwed - I forgot it on day on a 2 hour train ride to a client - it was hard to use without the pen
No attached keyboard (you could use a USB keyboard, which I always carried with after forgetting the pen, incident.)
Small memory / slow processor
Applications not designed for the form of the device
Heavy
Cost - $2800 in 2004!

I also have been using the Logitech IO Pen (Anoto, Pulse, ...) since 2004. This device writes on regular paper with a special map of dots in the paper to allows the pen to record what you write.

It also has intelligence that allows software to provide for areas that if you mark them with a checkmark it will trigger the software to run an app. It supports ICR and handwriting conversion to text, ... great for capturing writing / drawings without a big, bulky copputer. Let "threatening" in a meaning. Prevents getting distracted and surfing the web in a meeting. Its designed to write on and does that well. Downside - had to plug pen into USB cradle to get the images out, custom paper needed, only one color images.

Good

Price $150
Light
Easy to use
High res - 300 dpi - equiv of a 3300 x 2400 pixel screen
non-intrusive - nobody knows its recording things like typing on a PC does

Bad

Battery life - 3-4 hours
docking cradle needed
one color, no ability to erare
no display - paper doesn't show things only records as input device
handwriting recognition is bad input and prone to errors.
hand cramping
no really good apps
lose the pen and your out $150!
proprietary paper

I've had a Toshiba m205 Tablet since 2004. I used it to teach classes at NYU. Using the pen to write on power point in real time, highlighting things, drawing diagrams, manipulating things.

I used it in JAD sessions with a team developing software design. Used it to draw UML diagrams, etc.

Used it as a regular laptop with its keyboard to write code, word docs, etc.

On a plane, to watch DVDs, I would spin the screen around so it was facing up, but not snapped down covering the keyboard but tiled for viewing. Avoided the fatigue of holding it and the impossible angle that a cramped seat forces you to have it at.

Used the pen for retouching photographs on the screen (not terribly good for that, BTW, not easy to see what you are drawing on.

I used it to READ BOOKs and highlight them! Yes, using PDF / Word editor and PDF or word based books this worked GREAT! Or using a special printer driver that would create a file for OneNote. Then I could use OneNote to read and highlight / write comments in the margins. Years before the kindle / nook / eReaders / iPad.

Good

pen was great for driving power point like it was a whiteboard you could write on
supported erasing by using the "eraser" end of the pen
Pen - Great for drawing diagrams but bad for entering text
Reading books (better res would have been nice)
Attached keyboard because handwriting as input sucks - keyboard is faster / more accurate / more natural (yes).
Memory - max 4 GB (that was big back then)

Bad features

lose the pen your out of luck (so I carried an extra.)
a pen is not a great general purpose input device. if it had mutitouch, it would have been better for more different things, but this was 2004.
weighed too much (6 lbs)
battery life was 2.5 hrs.
screen real estate was 1024 x 768 and 11" diagonal (similar to a iPad)
few apps that were design for that form of device
cost $3000 in 2005!
cost of applications

Apps weren't designed for that form factor and thus were often clumsy to use.

The way you use a mouse versus a pen (vs. multitouch vs. voice) require different UI designs for best functionality.

As with many ideas, they make better sense in your head then in your hands.

The pen as an input device excels at certain tasks and fails at others.

The mouse excels at certain tasks and fails at others.

Keyboard input - yada yada yada.

Voice input - yada yada yada.

Multitouch input - yada yada yada.

so what do you do? support all? of focus on certain types of problems and optimize for them?

Thought experiment - ever play piano? A piano is a great input device for certain things - you can enter data and time relationships between that data, in real time, along with the dimension of velocity (how hard/fast) you enter press the key(s). Why not use a piano to enter text in a word processor? You could map the alpha bet to the keyboard. You enter whole words by pressing multiple keys simultaneously, like playing a chord on the piano. How hard you hit a key could determine the font size or bolding or italics.

This idea is not new, back when the mouse was conceived, the 5 key chording "keyset" was also created at SRI by Englbart.

You could even consider Morse Code and the Telegraph key as a input device!

What differentiates what works and what doesn't? Many times its the efficiency vs. effort to learn curve. Sometimes its ease of use in the intended environment (think voice control underwater vs. a keyboard, or touch interface vs. a mouse on an oil drilling platform, ...)

So, what does all this have to do with "the price of tea in China?" or the iPad?

Apple has reinvented the past to define the future.

They understand what works and when and why.

Things that apple gets:

Looks cool
Branded as "cool"
Initial price is low
Lightweight
Long bat life
Tailor the apps for the device
Fewer features that work better is superior to "swiss army knife" approach.
Focus on a few uses of the device and do them well
Lower cost for software - a buck or two at the iStore
Software that doesn't have "featuritis "
Multitasking eats processor cycles - limit it to single tasking to start with

Will Apple change the game with the iPad? YES

"All of the built-in apps on iPad were designed from the ground up to take advantage of the large Multi-Touch screen and advanced capabilities of iPad. And they work in any orientation. So you can do things with these apps that you can’t do on any other device." - Apple Website 2010

They did with the MP3 player, with the cell Phone, ...

I believe that Apple is good at "misdirection." You think the iPhone is a phone, but its really a portable computing device that is more powerful than my Toshiba Tablet from 2005! You run more apps than you do talking on it, I'm betting.

The iPad is a purpose focused device for reading web pages, books, watching video ... until it gets used for lots of other things, too. You'll need a bunch of them for the house, not just one big powerful one. Its cloud computing savvy. More stuff run in the cloud means less needed in your laptop.

So watch as Apple changes the game and the competitors scramble to copy the hardware approach of the iPad while missing the real energy behind the iPad - cheap software that developers will fund and Apple will profit off of (look at the MP3 player vs. the MP3s, the phone vs. the apps vs. the monthly plan.

Apple is, after all, in the business of selling you HARDWARE under the guise of selling you a lifestyle

Its hard to pirate hardware, easy to pirate software, can you pirate a lifestyle? ... hmmm

Steve Jobs has failed often when he tried the super advanced tech approach - Lisa Computer, Next Computer, ... but succeeded with the stripped down version that then grew back into the super-duper version - Mac, OS X, ...

Welcome to the future, Apple style.

Standing on the Shoulders of Giants, Apple didn't invent much of what you think they did (neither did Microsoft, Xerox PARC)

Logan Poelman — Thu, 25 Mar 2010 21:00:00 GMT

Douglas Engelbart, et al., at the Stanford Research Institute invented the first mouse prototype in 1963.

They demoed a windowing system in 1968.

All funded through DARPA / NASA / Army via Gov Grants.

Watch history http://www.1968demo.org/web.html