Bobtuse

Women on the Rise

noreply@blogger.com (Bob MacNeal) — Tue, 28 Jul 2015 14:49:00 +0000

illustration by Sascia Däumichen

The demand for women programmers is on the rise because the software industry realized it has a long-standing brogrammer problem and remains economically stunted from a lack of gender and socio-economic diversity.

After decades of observing teams, I recognize that braggadocious brogrammer behavior, lock-step certainty, and baseless hubris, diminishes the opportunity to foster a learning team.

In my experience,

A diverse team raises the bar of social intelligence and civility.

Contrary to popular notion, few people want to get pummeled by a sophomoric pack of Nerf Gun Nincompoops for breaking the build or making a mistake.

Software is no longer produced by pre-historic rock quarry workers like Fred Flintstone.

"People unfamiliar with the nuts & bolts of software development imagine it's an engineering process, but it's a profoundly human activity."
― Alan Cooper

Diverse, learning teams are much more fun, and by extension, more productive than mono-cultural, humiliation-centric teams.

REFERENCES

Breaking the Build is Not a Crime, by Tomasz Nurkiewicz, 5 February 2013;
More Than A Pipeline Problem: In Search Of Diversity In Silicon Valley by Rachel Martin, NPR, 26 July 2015;
Say No to Brogrammers, Bobtuse Bobservations, 26 May 2012;
Social Intelligence, Wikipedia;
The Learning Team, Bobtuse Bobservations, 27 April 2014;

Why I Dig Bootstrap

noreply@blogger.com (Bob MacNeal) — Tue, 31 Mar 2015 14:01:00 +0000

Bootstrap is one of the most significant web development improvements in recent years because it standardizes on class names for common css (cascading style sheets) for html layout and html page elements (buttons, select options, etc.).

Bootstrap enables you to develop

display-size-independent web & mobile browser interfaces.

By following simple conventions, your layout will respond to display-sizes without heavy lifting.

Bootstrap's open source community is actively pushing updates to this GitHub repo. It's a vibrant, continuously-improving styling and layout option you'd need a compelling reason to ignore.

Why burn up cycles hand-rolling spaghetti-fied css?

I've found Bootstrap helps a green-field development team leap-frog much of the front-end set up jicky-jack. Bootstrap conventions also help with UI unit-testing and functional testing because the html elements have standard class names. When it comes time to grab a handle to an element to exercise an event and assert against the result, you know which class names to reference.

Bootstrap has widespread adoption and continues to grow in usage.

Every developer knows it (uh...or at least the people I work with), so it's easy to plug in a new person with the confidence she won't be baffled by Bootstrap class names, layout, and conventions.

Bootstrap layout uses html div tags for rows and columns. All you have to remember is that 12 is the magic number.

Bootstrap enables heads-down developers to do rapid software prototyping for a startup product without the interface looking like shit. Your product simply looks like the zillion other Bootstrap applications → clean and consistent.

Bootstrap supports a collection of glyphicons that let's you select icons for common functions like edits, deletes, and event notifications. I use this cheatsheet to find the most communicative icon for the function I'm implementing.

Complete glyphicons collection here

Over time if your product gains traction in the market, you can hire a designer to improve the look of your product without changing css class names.

CI Saves My Bacon

noreply@blogger.com (Bob MacNeal) — Sat, 21 Mar 2015 15:31:00 +0000

One production pattern I've found indispensable is Continuous Integration. CI saves my bacon.

Recently I've found continuous delivery used on top of CI is a production pattern that helps me and my teammates produce working software.

Continuous Integration

Continuous integration or CI is

The practice of running tests on a non-developer server every time a developer pushes potential change sets to a shared source code repository

Florian Motlik, CTO of the CI/CD cloud service CodeShip wrote in Quora:

"This has the tremendous advantage of always knowing if all tests work and getting fast feedback. The fast feedback is important so you always know right after you broke the build (introduced changes that made either the compile/build cycle or the tests fail) what you did that failed and how to revert it."

Pushing code to a remote repository which in turn awakens the CI server to grab your new code and run your test suite, enables you to continue working without waiting for the test suite to complete on your local machine. When tests are run every time a developer pushes code, red flags might pop up, but tend to get fixed in short order. That feedback is reassuring.

One observable behavioral pattern is that many developers, including me, fail to consistently run the test-suite before pushing code. This is particularly true as the code base grows larger, the corresponding test suite grows proportionally larger, and the act of running the test suite exceeds a 5 minute threshold. I've worked gigs where running backend unit tests, front-end UI unit tests, and headless browser integration tests, took over 30 minutes to complete.

Yesterday I made a Rails schema migration to change a column name and to subsequently make it non-nullable. I fixed a controller test because I knew the schema update would have caused it to fail. I generally tend to make frequent commits following small changes. I committed and pushed the new code to our GitHub repository and continued working on the subsequent non-nullable migration. A few minutes later, the CI server reported back red-colored cackage (see below).

CodeShip's CI server indicating bobmacneal pushed code with broken tests

Drilling into the failure notification, I was given a handle to four other tests my schema change broke. I fixed the failing tests, committed, and re-pushed.

Test-driven developers, and their purist brethren test-first developers, would protest that if I was doing things right, I wouldn't be pushing code with failing tests. They're right. Sometimes I cut corners. Like many developers, I'm frequently not the perfect craftsman.

Knowing I'm flawed, I like having a safety net so I can continue the uninterrupted flow of my task knowing the CI server has my back.

I prefer the convenience of hosted continuous integration over standalone continuous integration (see a comparison of continuous integration software).

Continuous Deployment

Built on top of continuous integration is CD (continuous delivery or continuous deployment). Continuous delivery is

The practice of releasing the latest version of your code to a production, or production-like environment, every time new code is merged to a designated branch after a successful run through the CI gauntlet.

Once configured, a cloud-based continuous delivery service makes deployment to any environment frictionless. Continuous delivery supports the agile principle of producing working software.

I like CodeShip. CodeShip is a well-executed, visually attractive, easy-to-configure, cloud-hosted service that provides seamless continuous integration and continuous delivery.

REFERENCES

Comparison of continuous integration software, Wikipedia.
Tools and Services I Like, Florian Motlik, 29 November 2014.

Founders as Programmers?

noreply@blogger.com (Bob MacNeal) — Fri, 06 Mar 2015 18:47:00 +0000

A founder asked

While outsourcing my startup, should I learn programming or just focus on customers and scaling?

Founders don't need to learn programming.

Outsourcing is a good call, but never if the intent is to outsource on the cheap.

Don't skimp on developers if your product is software.

Founders need to find the most talented software producers money can buy. A software producer is steeped in:

Software developers need cash on the barrelhead. Never insult them with equity propositions. If you do, they'll sniff you out as an amateur.

Founders are on the hook to provide the developers with a clear picture of what the product should be at any given time as the production team iterates to a sustainable business model.

Scaling?

You wish. First things first.

Focus on customer discovery.

Prepare for the realization that your original idea sucked.

Let the discovery process guide and inform the search for a viable model;
Don't rely on notions and opinions about customers;
Humbly and diligently acquire the hard facts about customers and the market.

Founders are detectives. They pursue intel on customer pains & gains. Then they fit an offering to address them. The Business Model Canvas helps organize the detective work.

Pursue reality over wishful thinking.

A founder needs to attract the best software producers, then trust them to deliver the product vision.

The more relentless founders are in pursuing actionable, the more the production team will trust the founder's vision of the offering.

REFERENCES

Business Model Canvas.
The Startup Owner's Manual by Steve Blank and Bob Dorf.

Ten Outsourcing Considerations

noreply@blogger.com (Bob MacNeal) — Fri, 27 Feb 2015 02:07:00 +0000

Software developer testing with JUnit

Ten outsourcing considerations when choosing a software development team:

Are they local?
Are they recommended by someone you trust?
Are they demonstrably adept in DevOps (Continuous integration, Continuous delivery, Product stewardship*)?
Are they tech-stack agnostic?
Do they have collaboration chops (Pair programming, Pull requests, Distributed version control system)?
Are they hip to quality considerations (Interaction design, Test-driven development, Test automation)?
Are they a learning organization?
Do they have soft skills?
Are they product-centric rather than project-centric?
Do they feature a high producer (team lead developer, developers) to non-producer ratio (i.e., architects, business analysts, scrum masters, account managers, reporting jockeys)?

^*Product stewardship is an emerging topic for a future post. Subscribe or check back.

Chief Agile Officer?

noreply@blogger.com (Bob MacNeal) — Fri, 06 Feb 2015 11:00:00 +0000

Does anyone need a Chief Agile Officer? Not is this galaxy.

Imagine an old-school and a new-school narrative:

1. Old-School

Imagine a storied company called Hammer & Sons.

Some 20 years after amazon.com revolutionizes web commerce, Hammer's CEO Ken Cretaceous realizes he's got no direct or indirect online sales channel. A fat cat buddy who shares a third of Ken's Hawker, hands him a copy of some Gartner drivel called Doing the Agile as they cross paths on the tarmac.

Before cruising altitude, Ken swallows doing the agile as the antidote for his staggering lack of foresight. As a profoundly unimaginative, but not atypical reactionary executive, Ken Cretaceous thinks doing the agile is a shortcut to Hammer's online sales revenue.

Suppose Ken hires you to coach his people on doing the agile. You're jazzed. Ken greets you with an enthusiastic back slap. Gracious to your benefactor, you don't correct Mr. Cretaceous when he pronounces agile as agīle with the long i.

You're a popular speaker at conferences. You're a talented agile coach. Over a handful of workshop sessions, you post some modest gains at Hammer despite marginal developer infrastructure and dubious developer talent.

Before you can get to your Kickstarting Continuous Integration session, Ken cuts you loose because he wants to save some doing the agile money to buy an enterprise agile tracking tool. He thanks you for "turning the organization upside down" even though he no closer to peddling hand-forged specialty hammers online than when Silas B. Cretaceous opened the first Hammer & Sons plant in 1899.

The following Monday, Hammer & Sons reverts to cretaceous period behaviors. Hammer & Sons is a manufacturing company, not a software company.

When does more of what you were doing make sense for this company?

Imagine another Hammer scenario where Ken Cretaceous hires you as a full-time Chief Agile Officer. Your business card reads Chief Agile Officer, Hammer & Sons. In a month, you hate yourself. You hate yourself because of:

the massively un-processable cognitive dissonance,
the slovenly business patterns you couldn't reset in two lifetimes, and
the breathtaking malaise of your fellow employees.

You force a smile at Hammer's Free-Pizza-Friday despite your maxim that workplace pizza is always a condescending gesture.

Worse yet, you pose a threat to Hammer's CIO because like CIOs in most non-software organizations, she conflates IT infrastructure with software product development. You and she are at cross-purposes budget-wise and mission-wise. Your job is to pull rabbits from a hat. Her job is to make sure someone remembered to gas up the back-up power generator.

You realize that Ken Cretaceous is an incandescent bulb ― a dimly lit bulb.

Many Chief Executives are still trying to extract the last pennies from the industrial revolution.

There is no dosage of doing the agīle that will fix Hammer & Son's non-renewable fossils!

Finally, whatever non-calcified developers you have on your team resent having you as yet another non-producing overlord.

The thing is, one could near-shore Hammer's online sales to contract developers who could Shopify, Bootstrap-ify, GitHub-ify, and CodeShip-ify it it in 3 months for roughly the Chief Agile Officer's salary.

Agile is fine when used as guiding principles by talented developers who grok its essence. But in the hands of C-suite nincompoops, or a ponderous PMO, agile becomes toxic.

2. New-School

For the new-school example, imagine you are bootstrapping a software product. Your most essential people are developers who are proven at producing software. Without proven producers, you're vapor. You're wearing many hats, but you gleefully recall Facebook bought a photo sharing app for $1 billion 18 months after launch.

Now imagine your product is attracting and retaining a sizable revenue producing community. This product is your baby! You bootstrapped it on creativity and moxie with the best developers you could find. You want to hang on as long as you can. The question is:

Could you ever imagine, in your wildest knock-it-out-of-the-park conception of success, hiring a Chief Agile Officer?

No. A willingness to learn ― the most succinct definition of agile ― is already steeped in startup culture.

One can imagine a distant galaxy where a Chief Agile Officer makes sense, but not in the Milky Way.

Soft Skills

noreply@blogger.com (Bob MacNeal) — Thu, 18 Dec 2014 14:39:00 +0000

Making software is a profoundly human activity. Successfully produced software is made:

by teams.
for people to use.

Interpersonal communication and mindset are increasingly important for developers.

An overlooked lesson from the Agile movement is:

Producing software products doesn't need or require projects or managers. Successfully produced software is laser-focused on People, Products, and Teams.

Another overlooked lesson is the growing demand for a mental shift. Successfully producing teams have adopted:

A state-of-mind over a set of PMO rules.

Producing software is a creative act more than a prescriptive act. Often developers must discover the right balance between generative thinking and evaluative thinking:

What could the product do? and
What should the product do?

We have learned that good things happen when we make a pact to:

Discover & adapt, rather than robotically design & implement.

Humility trumps ego. Make a practice of approaching your teammates and products with Beginner's Mind. Everyone aspires to mastery, but no one becomes the expert.

Practice listening.

"We have two ears and one mouth so that we can listen twice as much as we speak."
― Epictetus

Practice being a good teammate. Introspection helps. Ask how-can-I questions.
Ask How can I:

be more helpful?
become a better teacher?
become unflappable?
become non-judgmental?
make people laugh?

“There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.”
― Ernest Hemingway

Start Slackin

noreply@blogger.com (Bob MacNeal) — Sun, 07 Dec 2014 23:52:00 +0000

The infrastructure supporting the flow of communication has become an iteration zero concern. For software developers, a team chat application is becoming as fundamental as a GitHub repository.

Slack is a San Francisco based chat startup with a well-executed product that's rocketing in popularity. Slack's marketing pitch is

We’re on a mission to make your working life simpler, more pleasant and more productive.

Slack Chat Client

After a few months having used it with a few product teams, I'm convinced Slack is delivering on their pitch.

At the moment I'm using Slack with two product teams for different customers. In the past I have used other chat applications like:

Colloquy (open-source for Mac OS X); and
HipChat (by Atlassian).

Slack fills a niche by being less geek-centric than Colloquy and by being spiffier and more feature-rich than HipChat. Colloquy and HipChat remain fine products, but I've a growing preference for Slack.

Wildly Imagined Vintage Slack Poster

Using Slack, I like that:

One can easily configure different client gigs and then switch between them on the handy left nav;
One can easily create new team channels;
One can easily toggle between team and private channels;
Individual teammates may chat privately in the private channels; and

GitHub Commit Stream

Developers reap the benefits from the information stream via GitHub, Heroku, and Jira integration.

Chat is a forum for knowledge sharing. It has the potential to build team camaraderie even when your teammates work from a remote location.

"Contextual conversation is likely to become the dominant social motif of the next generation of work-technology apps."
— Stowe Boyd, tweet @stoweboyd

REFERENCES

Chat, Slack, and the Panoptic Telecommute, Scott Rosenberg, 13 Oct 2014.
Contextual conversation: Work chat will dominate collaboration, Stowe Boyd, Gigaom Research, 30 June, 2014.
Why these startups think chat apps are the next big thing in workplace collaboration, Jonathan Vanian, 1 Aug 2014.

Pair Programming in Perspective

noreply@blogger.com (Bob MacNeal) — Sun, 07 Dec 2014 18:12:00 +0000

Annual Mermaid Parade
Coney Island, 2012

I offered my 2¢ on this question from another developer:

Would you consider joining a company where pair programming is an essential part of software development?

One long-standing lesson from Extreme Programming is:

Programming in pairs improves quality.

With qualifiers, few dispute this assertion.

Recently I've learned of mandates for pair programming which is mildly alarming. A team at BestBuy does pair programming ...all the time. This particular pair-programming-all-the-time initiative had the unintended consequence of chasing off one of the most test-driven, quality-focused craftsman I have pair programmed with, and learned from, in years past.

Let me state this:

Paired programming mandates are a bad idea.

Mandates in general are a bad idea. Producing software is a creative act. Mandates stifle and demoralize.

Pair programming is most helpful when on-boarding new team members, or when intentionally pairing an experienced developer with an inexperienced developer.

Software produced in pairs is typically superior, but not always the smoothest tack. Sometimes pairing is jarring to the soloist's creative flow. At times, pairing is downright inefficient.

It's common to achieve quality results on par with pairing by having peer reviews and team discussions. I'm an enthusiastic cheerleader for the Pull Request Workflow popular on GitHub and BitBucket (see Pull Requests for Teams). Pull Requests allow for collegial discussions that lead, more often than not, to quality improvements.

Mandates are a red-flag for team and organizational inflexibility. My answer to the developer's question "Would you consider joining a company where pair programming is an essential part of software development?" is a qualified no.

Two heads are usually better than one, but not always.

The development community has realized significant strides from XP and Agile, but shouldn't we be judicious about — and mindful of — how we apply what we've learned?

More ain't better, particularly when it's dictated over pragmatism or common sense.

Not every arrow in the quiver suits a situation.

REFERENCES

Extreme Programming, Wikipedia.
Paired Programming, Wikipedia.

Raising Products

noreply@blogger.com (Bob MacNeal) — Thu, 23 Oct 2014 05:26:00 +0000

Sunrise to sunset, products have a time-honored cycle. In the realm of software development, I prefer Products over Projects.

Product life-cycle

Who are the best people to raise a software product? As a contractor in dozens of IT departments, I've found IT to be the most ill-staffed and culturally stifling place for raising software products.

IT is where What's Possible goes to die.

For user-centric software developers, having the human activity of making software under the yoke of an IT department is like a fish in outer space.

Wrong environment. Wrong vibe.

What should be the goals and purposes of product development are frequently at odds with the raison d'etre of IT. By popular definition, IT deals with all things electronic.

Information Technology - Often the name of the part of an enterprise that deals with all things electronic. Free On-Line Dictionary of Computing

All things electronic is hardly a human activity. Successful software involves people. The most successful software focuses on human pains and gains.

People unfamiliar with the nuts & bolts of software development imagine it's an engineering process, but it's a profoundly human activity.
― Alan Cooper

The product-focused team is rooted in the common cause of serving people by relieving pains or offering gains. In Product vs. IT Mindset, Marty Cagan chose the words Mercenaries and Missionaries to distinguish the IT Mindset from the Product Mindset.

In an IT mindset organization, product and tech are mercenaries. There is little to no product passion. They are there to build whatever. In a product organization, product and tech are missionaries. They have joined the organization because they care about the mission and helping customers solve real problems.
― Marty Cagan

IT programmers tend to make marginally consequential changes to existing applications. The applications built and supported by IT serve people in other departments ― users that frequently harbor contempt for IT. IT programmers derisively refer to these users as The Business.

Because there is a death of product passion in IT, programmers tend to gold plate dubious features behind the guise of some perceived benefit to The Business. If The Business doesn't use the feature, no one loses their job or their life-savings.

Contrast the IT mindset to a product-centric developer's mindset in a startup. Product-centric developers know the existential narrative is:

Deliver value or die.

For software startups, continuous innovation and connecting with customers are dual imperatives. On the other hand, IT departments focus on support and execution over innovation.

"A business that isn’t investing in tomorrow, is a business that’s already in the process of dying.”
― Reid Hoffman

IT departments are better equipped to handle knowns than unknowns. IT is ladened with processes, governance, and gratuitous ceremony.

"Every time another execution process is added, corporate innovation dies a little more.”
― Steve Blank

The product mindset is that the product is paramount so all but the most pragmatic of processes falls by the wayside. Products have an inception and an end of life. IT tends to fund ongoing projects, rather than products with a beginning, middle, and end.

Delivery teams deliver software products - not projects - that run from inception to retirement.
― Jez Humble

Product-minded behemoths like Apple, Amazon, and Google demonstrate that people-pleasing products are not limited to startups.

My philosophy is that everything starts with a great product. So, you know, I obviously believed in listening to customers, but customers can't tell you about the next breakthrough that's going to happen next year that's going to change the whole industry. So you have to listen very carefully. But then you have to go and sort of stow away -- you have to go hide away with people that really understand the technology, but also really care about the customers, and dream up this next breakthrough. And that's my perspective, that everything starts with a great product.
― Steve Jobs

To raise my killer product, I'm determined to partner with people steeped in a product mindset, then rally them around our product to change the world.

REFERENCES

DevOps and the "Product-Centric" Approach, DevOpsGuys, 13 December 2013.
Nuke & Pave Information Technology, by Bob MacNeal, 23 March 2009.
Product vs. IT Mindset, by Marty Cagan, Silicon Valley Product Group, 14 October 14 2014.

Say Why to Estimates

noreply@blogger.com (Bob MacNeal) — Wed, 10 Sep 2014 03:33:00 +0000

Agile estimation surfaces a clash of cultures. Broadly speaking the Agile community consists of makers & managers.

The clash between makers & managers distills to motivation:

Why & What —motivates makers
When & How Much —motivates managers

Makers make. Managers manage.

Estimates are a wild-assed-guess at How Much. A quote is exactly How Much.

If you suggest to a manager that there is a distinct and important difference between an estimate and a quote, she won't get it. Still, I prefer a gentle reminder — particularly with newly forming teams. If nothing else, such a reminder has the potential to lead to a better understanding of the Terms & Conditions between managers and makers.

Reminder: There's a difference between an estimate and a quote.

Because of the cognitive disconnect managers have about estimates, few seasoned makers take estimates seriously.

Some makers will sandbag an estimate by suggesting an inflated number. Other makers will confidently declare a random number, for example,

Just say three.

"Just say three" is my estimation mantra. Just say three is an artifact of the absurd notion that some tracking tool needs a number attached to a story. Makers, as they're eager to get back to the joy of making, will use "Just say three" to fulfill the immediate desires of the tracking tool jockey.

I suggest managers consider the necessity of the prevailing agile estimation pattern. Estimates, when so frequently treated as quotes, extract a cost in maker trust & product quality.

Say Why to Estimates.

Every team should attempt the Why conversations about process artifacts like estimates. Estimation is not a sacred cow.

REFERENCES

Quotation vs Estimate, Estimates.info.

The Learning Team

noreply@blogger.com (Bob MacNeal) — Sun, 27 Apr 2014 21:27:00 +0000

A Learning Organization seems so obviously desirable as to be ubiquitous yet most of us will never experience one.

Learning Organization
A term for an organization that fosters ongoing learning among its members. Because learning is ongoing, the organization continuously transforms itself.

If we can't fix our inept organization, perhaps we can influence our team.

All politics is local.
― Tip O'Neill

All politics is local means that our success is tied to our ability to understand and influence our constituents.

My constituents are my teammates.

We owe ourselves the courtesy of modeling the kind of behavior we want to see in our teammates. We owe ourselves the courtesy of striving to be good learners and aspiring to be good teachers.

“You cannot force commitment, what you can do…You nudge a little here, inspire a little there, and provide a role model. Your primary influence is the environment you create.”
― Peter Senge

Fun teams cultivate learning. The rest suffered from varying degrees of toxicity. I resolve to choose fun. I urge you to join me.

People unfamiliar with the nuts & bolts of software development imagine it's an engineering process, but it's a profoundly human activity.
― Alan Cooper

A Learning Team

The closest I've been to a learning organization has been flashes of a learning team practiced by me and my teammates.

If your teammate responds to a question by affirming, "That's a good question", all indicators point to a learning team.

A well-tended and searchable wiki ― thanks Ward ― that has up-to-date on-boarding instructions, and frequently used command sequences, is one sign of a learning team. On the other hand, admonishing a teammate to "look it up on the wiki" is a red flag your teammate is missing a teaching opportunity. Such opportunities occur whenever a teammate asks a question.

Missed teaching opportunities occur whenever a teammate stops asking or regrets asking.

A few red flags that you're falling short of a learning team are:

Defensive Postures
Shaming Mechanisms
Cynicism

Defensive Postures:

We often recognize defensive postures in ourselves and in our teammates. Defensiveness is a burden and a buzz-kill. Excise it.

“It is not the absence of defensiveness that characterizes learning teams but the way defensiveness is faced”
― Peter Senge

Your teammate doesn't want a knife in the back. He wants to you have his back. When your teammate is defensive, she's probably not pro-active.

Shaming Mechanisms:

Sometimes the original idea for a practice, or the spirit of an idea, gets lost over time.

Practices should never devolve into a mechanism for shaming.

Examples of sound practices that have gone toxic:

Continuous integration is a highly recommended, ongoing health-check, BUT never shame a teammate for breaking the build, or for failed functional tests. I suffered through an immature team that handed around a stuffed Build Monkey to anyone who broke the build. I deep-sixed the monkey.
Test-First is a valuable learning tool, as is Test-Driven. Both play a role in ensuring quality. BUT avoid shaming a teammate for not adopting them as a matter of course. If one or the other is an agreed upon team practice, then reward good behavior rather than shaming people for slip-ups or for regressing under pressure.
Estimation and burn-down charts, once handy tools to make wild-ass-guesses at story sizes and to make progress visible, have become blunt instruments for flogging in the hands of command-and-control managers. NEVER use a tool or a process to hurt people.

Process alone is usually innocent. It is converting ideals into expectations that can be toxic. For more on shaming, see Say No To Brogrammers.

Cynicism:

Cynicism grows from the loam of unmet expectations. One tip:

Don't romanticize your teammate's abilities to be a "craftsman" ― particularly if he must measure up to a poorly articulated definition of craftsmanship.

By avoiding romanticizing the notion that developers are craftsman, you'll be better equipped to avoid the psychological baggage of unmet expectations.

“In combating cynicism, it helps to know its source. Scratch the surface of most cynics and you find a frustrated idealist – someone who made the mistake of converting his ideals into expectations.”
― Peter Senge

Cynicism grows from trying to change too much. Forget about the larger broken organization for now. Remember all politics is local.

Get to root causes. If it's something the team can fix, fix it before it devours all optimism.

Lastly, try modeling vulnerability rather than oozing cynicism. Your teammates will appreciate it.

Getting to the Learning Team

A learning team, like a happy family, requires practice and vigilance. A learning team gets sustenance from people expressing ideas and opinions with reckless abandon.

Remember everyone has a different take. The spectrum might range from Michelangelo to Cowboy Coder.

To voice an opinion or posit an idea we need to feel comfortable speaking up and we need to be practiced at listening. A learning team starts by modeling listening, practicing Beginner's Mind, and aspiring to teach.

"In the beginner's mind there are many possibilities, but in the expert's mind there are few"
― Shunryu Suzuki

Learning frequently calls upon us to step out into the vast unfamiliar. Learning can make us uncomfortable because it means exposing our weaknesses. But humility goes a long way toward learning. Practice humility.

The place I'd start to cultivate a learning team is a distributed source control system that supports the Pull Request Workflow.

Pull Request Workflow:

If you use no other means to get to a learning team, try the Pull Request Workflow on GitHub and Bitbucket. The PR Workflow encourages you and your teammates to:

publicly view proposed code changes,
publicly offer options or discuss alternatives, and
approve all changes ― shared responsibility.

Two outcomes of the PR workflow are:

Quality - Under the assumption that two-plus heads are better than one, quality invariably improves from peer-reviewed code; and
Learning - Newbies can view other's code before it's merged and benefit from the public dialogue about how the code might be improved. Old hand's are given the golden opportunity to learn and the golden opportunity to teach. Double gold. Be respectful. No one loses.

See Pull Requests for Teams for more details.

An ideal teammate teaches you something and wants to learn from you. Seek or grow a learning team. Resolve to choose fun.

REFERENCES

Beginner's Mind, Dumb Luck & Agility, Bobtuse, 20 April 2009.
Pull Requests for Teams, Bobtuse, 28 August 2013.
Say No To Brogrammers, Bobtuse, 26 May 2012.
TDD is dead. Long live testing. David Heinemeier Hansson, 23 April 2014.
The Fifth Discipline: The Art & Practice of The Learning Organization, Peter Senge, 2006.

ACKNOWLEDGEMENT

Hat tip to Chris Bartling for introducing me to aspects of the learning environment and for nudging me into the vast unfamiliar of open source.

Naming Conventions

noreply@blogger.com (Bob MacNeal) — Sun, 27 Apr 2014 16:30:00 +0000

On my last three software teams I have had a teammate named "Bob". What are the odds of a Bob having a teammate named Bob? I can understand a Horatio or a Cuthbert, but not another software guy named Bob.

Bob is a rare name. Ask any SETI scientist. Okay so maybe the software world has a notorious Uncle Bob, but I suspect Uncle Bob is a actually a closet Robert (see Robert Cecil Martin).

Before my software gig, I probably encountered two or three Bobs in my lifetime, one of whom was my father. It's pure dumb luck that I'm not a Bob Jr. Being branded Bob Jr. would be worse than having a Microsoft operating system named after you.

But there's a solution to this madness. The next time I encounter another Bob, I'll diffuse any confusion by pulling a Steve Jobs, who when he encountered a designer named Steve on the iPhone team, declared,

"Guess what, you’re Margaret from now on”. ⁽¹⁾
― Steve Jobs

Move Deliberately & Build Things

noreply@blogger.com (Bob MacNeal) — Fri, 07 Feb 2014 01:10:00 +0000

Bell Labs technicians preparing the
Telstar communications satellite for
launch in 1962.

Describing the post World War II golden age of innovation in the US, Jon Gertner posits that the Bell Laboratories' motto might well have been:

Move Deliberately & Build Things.

And build they did. Bell Labs was the most prolific innovation factory of the 20th century.

Reviewing The Idea Factory, Gertner's book about Bell Laboratories innovations, Walter Isaacson suggests that the first intercontinental phone call between New York and San Francisco, master-minded at Bell Laboratories, ushered in the novel model of the collaborative industrial organization — an organization that deliberately seeks and models cross-functional, cross-disciplinary teams.

The problem was one that required not just engineering skill but advances in pure science. They needed, among other things, to create a repeater or amplifier for the electric signals so that they would not attenuate after a few miles. Thus was the seed planted for a new collaborative industrial organization — teaming up theoreticians, experimentalists, material scientists, metallurgists, engineers and even telephone pole climbers — that eventually became Bell Labs.
― Walter Isaacson

Isaacson asks,

What causes innovation? Why does it happen, and how might we nurture it?

In The Idea Factory Gertner offers insights into how an engineered organizational structure, and an intentional physical layout led to and sustained decades of unprecedented innovation if the US until the monopolistic breakup of the Bell System in 1982.

Contrary to the popular notion of a lone genius conjuring culture-changing inventions in the isolation of a garage workshop, Bell Labs inventions grew incrementally from teams of people with diverse expertise and temperaments. It grew incrementally from people learning from and extending the discoveries and inventions of their colleagues and historic predecessors.

If I have seen further than others, it is by standing upon the shoulders of giants. ― Isaac Newton (1642 – 1727)

One of the many triumphs of Bell Labs was to connect us through digital machines shrinking our collective cultural & communication sphere. And connect us they did.

Conveying break-through scientific theory into useful consumer products is incremental and deliberate. The product development path was rarely direct, rather setbacks and diversions were not only expected but redoubled resolve ― resolve to drive toward better and cheaper products.

REFERENCES

Inventing the Future, a book review of Jon Gertner's The Idea Factory, by Walter Isaacson, New York Times, April 6, 2012.
The Idea Factory: Bell Labs and the Great Age of American Innovation, by Jon Gertner.
True Innovation by Jon Gertner, New York Times Opinion, February 25, 2012.

Open or Closed

noreply@blogger.com (Bob MacNeal) — Sun, 12 Jan 2014 19:54:00 +0000

A closed door shields us from our shortcomings, but robs us of humanity's greatest currency ― sharing ideas.

Richard Hamming left many insights about learning to learn from his career as mathematician. Hamming retrospectively concluded that his cloistered colleagues had made less impact.

Bell Laboratories, where Hamming worked from 1946 to 1976, capitalized on the physical proximity of brain power combined with a floor-plan that co-mingled multiple-disciplinary thinkers and doers.

Bell Laboratories

"Traveling the hall’s length without encountering a number of acquaintances, problems, diversions and ideas was almost impossible. A physicist on his way to lunch in the cafeteria was like a magnet rolling past iron filings."
― Jon Gertner

The mixing of disciplines at Bell Laboratories, attributed to Bell Laboratories President (1951-59) Mervin Kelly, orchestrated harmony and tension that incited change. It was the frequency of change that sped up the flurry of innovation.

"If you're going to have progress, there has to be change. Change does not mean progress, but progress requires change."
― Richard Hamming

Traveling the halls of Bell Laboratories, Hamming observed the difference between those whose doors were open and those whose doors were shut.

I cannot prove to you whether the open door causes the open mind or whether the open mind causes the open door.
― Richard Hamming

An open door is an apt metaphor for an open mind. Hamming argued for diversity of input.

"You have to get wide cleave of what's going on."

He observed,

"Those who work with the door shut don't know what to work on. They're not connected with reality."

A closed door leads to fewer interruptions, and fewer interruptions allow one concentrated time to knock off problem-solving tasks. What if it's the wrong problem?

"The guys with their doors closed were often very well able, very gifted,but they seemed to work always on slightly the wrong problem."
― Richard Hamming

Learning is our imperative. The door is our metaphor. Today we have many channels vying for our attention or what Linda Stone calls Continuous Partial Attention. Paradoxically we must be both open and selective.

Being Open and Selective is a discipline of that demands daily exercise and vigilance.

REFERENCES

True Innovation, by Jon Gertner, New York Times Opinion, February 25, 2012
You and Your Research, lecture by Richard Hamming recorded June 6, 1995. This lecture was from the capstone course "The Art of Doing Science and Engineering: Learning to Learn" for graduate students at the Naval Postgraduate School.

Team Leads and the Opposable Thumb

noreply@blogger.com (Bob MacNeal) — Tue, 31 Dec 2013 11:32:00 +0000

I once observed an old-school project manager spew voice-quivering animus all over a Google Hangout.

Most people don't respond well to controlled anger, particularly millennials. The project manager's Hangout audience was a group of thirty-something software developers.

I thought, "He's lost them."

They wouldn't follow him into a company-sponsored happy hour.

Software developers have numerous opportunities to pick up and leave should the toxicity level of an organization rise.

Millennials bristle at the scent of an ass-clown.

The developers I have worked with are the polar opposite to the stereotypical slacker dude. They're Do-ers who bang out complex tasks.

Over the years my teammates and I have gotten reams of code pushed, reviewed, and committed. Productivity aside, work must be fun or millennials are done.

Command and control wind-baggery emanating from some two-bit spreadsheet jockey is a buzz kill that sends the best people packing.

Tim Elmore observed that millennials have intrinsic, extrinsic, and altruistic desires in the workplace.

Intrinsically, millennials want to:

feel they're growing;
do interesting work; and
be challenged in their tasks.

Extrinsically, they want their:

workplace to feel like family;
workplace to be social;
leaders to be adaptable with time; and
leaders to value their contribution and commitment.

Altruistically, they hope to:

contribute to their community;
contribute to society; and
change the world for the better.

A de facto leader emerges from within every software team. De facto means serving a function without being legally or officially established.

de facto (d fkt, d)
adj.

Actual.

Exercising power or serving a function without being legally or officially established.

Ideally your team's de facto leader is also your titular head where the operative root of titular is title.

“Your value lies not in status or title, but in the roots of your character and depth of your compassion.”
― Mollie Marti

The titular head might be at odds with the de facto leader, but given time the titular head will be willfully ignored.

Teammates of all stripes would do well to understand the spirit and essence of servant leadership. Mollie Marti wrote,

“A noble leader answers not to the trumpet calls of self promotion, but to the hushed whispers of necessity.”

A team lead should be an indispensable “opposable thumb” who cheerfully helps all the other “digits” grasp and handle stuff.

REFERENCES

Millennials in the Workplace, Huffington Post.
Three Realities to Know About Generation iY in the Workplace by Tim Elmore, Huffington Post, 10 December 2013.

The Big Wave Operating System

noreply@blogger.com (Bob MacNeal) — Thu, 14 Nov 2013 06:49:00 +0000

I surfed in my teens on tame East Coast waves. The draw to surf and to all aspects of water waves has never left me.

I seek and study waves in lakes, rivers, oceans, storm sewers, and boiling hot springs. And like a kid with a shoe box full of treasures, I have mentally cataloged all of the famous surf breaks from the chilly shores of Lake Superior getting pounded by an October gale to Bali the mystical Island of Temples with its thousand surfing waves.

Mavericks in a legendary Northern California wave near Half Moon Bay that breaks a half-mile out to sea and gets downright perilous to surfers when the winter swells get juicy.

Mavericks is also the name given to Apple's new operating system upgrade.

Mavericks is not so much the inspiration for a Beach Boys song as it is a symbol of Melvillian existential struggle.
― Stewart Sinclair

As an late Apple products convert, Mavericks strikes me as an appeal to the existential extremes of the extreme sports universe and a curious marketing decision. As a wave Mavericks is one of the ultimate big wave machismo rides on the globe -- a death defying free fall down a Matterhorn of water chased by an avalanche of roiling whitewater.

As for Mavericks the OSX upgrade, I haven't downloaded it because I rely on a MacBook Pro to ply my trade. I am patiently waiting for my smarter teammates to resolve any compatibility kinks with Chrome Driver that might confound our integration tests and potentially munge other development artifacts so I don't end up dead in the water.

REFERENCES

Apple's Private Beach, The Millions, by Stewart Sinclair, November 13, 2013.

Bootstrapping Lessons from Brooklyn

noreply@blogger.com (Bob MacNeal) — Thu, 17 Oct 2013 21:08:00 +0000

Before attending an October NSF I-Corps entrepreneurial workshop in Brooklyn, I finished the required reading:

Steve Blank's The Startup Owner's Manual: The Step-By-Step Guide for Building a Great Company, and
Alexander Osterwalder's Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers.

In this post I'll share a few things I took away from the workshop as an observer, and what I learned from the books.

As a launching point, a startup was defined as:

"A temporary organisation designed to search for a repeatable and scalable business model"

I was struck by the phrase temporary organization, but I suppose the idea is that once you become a revenue generating venture, you're no longer in the startup phase, rather you toggle the switches into an operational business where success is measured by how well you execute.

National Science Foundation I-Corps

The I in I-Corps stands for Innovation.

There is a shift afoot in the NSF away from funding stand-alone scientific research toward "broadening the impact" of basic research.

One way to broaden the impact of scientific research is to fast-track the science into products and businesses. Ergo we have I-Corps. From the I-Corps website:

The NSF Innovation Corps (I-Corps) is a set of activities and programs that prepare scientists and engineers to extend their focus beyond the laboratory and broadens the impact of select, NSF-funded, basic-research projects.

I-Corps, and the Brooklyn workshop I attended, are rooted in the soil of the Lean Startup movement.

Context: Customer Discovery & Lean Startup

Steve Blank is the de facto graybeard of Lean Startup. Lean Startup was proposed in 2011 by Blank's former student and entrepreneurial mentee, Eric Ries. While Ries popularized the movement beyond the software community, Blank contributed the essential first step:

Customer Discovery

With the exception of Customer Discovery, Minimum Viable Product, and the novel idea of iteratively testing a hypothesis about perceived customer value, much of Lean Startup is derived from the Agile / XP movement which has been used for over a decade in the software community.

Historical Context: Waterfall → Agile → Lean Startup

Software developers progressed from Waterfall to Agile and, more recently, into Lean Startup.

Waterfall is a sequential design process that was the canonical approach to software development for over 40 years. The stages of a waterfall are an unfortunate but apt metaphor for process rigidity (i.e., a new stage may not start until its immediate predecessor is completed).

Out of the process rigidity of Waterfall came the Agile Manifesto (Snowbird, Utah 2001).

Software developers have lived through the gains and pains of Agile implementations for over a decade (see Bottom-Up Change: The Agile Manifesto at 10). The lighter weight Agile taught us to embrace change, to adapt quickly to an evolving product vision, and to produce working software for the customer. Agile also taught us to iterate over bite-sized chucks of work and to reflect upon what we'd accomplished. We learned the value of incremental development. In short, we learned to

Plan, produce, and reflect.

Much of the Agile mindset is well-suited for starting a business.

The Business Model Canvas

Much of the workshop was centered about teaching graduate science and engineering students how to effectively use a Business Model Canvas. A Business Model Canvas is a template for developing new business models. The primary directive of a startup is to search for a viable business model.

"Startups search. Companies execute."
― Frank Rimalovski, NYU Entrepreneurial Institute.

In the journey to find out if your model has legs, the Business Model Canvas is used to organize your hunches about what will sell and who your customers will be.

Business Model Canvas

Over the course of the 3-day workshop, the Business Model Canvas became both narrative and scorecard. It was used for measuring progress in discovering the essential aspects of the model. Participants were charged with finding and interviewing potential customers so they could test their hunches. They were admonished to

"Get out of the building!"

And participants were urged to,

"Start thinking about the ecosystem...how the money flows."

Participants were instructed to frame, trim, and hone their product concepts (and the written descriptions of their products) so that the gist of the product was easily and instantly communicated to a less sophisticated audience.

"Frame the description of your product for your mother."
― Lyndsey Marshall Gray, NYU Entrepreneurial Institute

I observed graduate students, called Entrepreneurial Leads or ELs, struggling to coherently and concisely express concepts like Value Proposition or Customer Segments to a panel of business experts and instructors who grilled them. Several times a panel member blurted out, "Who cares?"

"This is delivery. We learn by doing."
― Jerry Engel, Berkeley-Haas School of Business

A Value Proposition is a promise of value. The Business Model Canvas has a box for Value Proposition, labeled VP. Participants were encouraged to write their value propositions as testable assertions.

A value proposition applies directly to one customer segment or another. The Business Model Canvas also has a box for Customer Segment, labeled CS. The workshop instructors stressed the importance of being able to map a value proposition to a specific customer.

When participants struggled with identifying their customer segments, they were encouraged to be concise and to think about the pointy tip of the arrow.

"Who are the people who will open their wallets first?"
―Lyndsey Marshall Gray, NYU Entrepreneurial Institute

Parting Wisdom

Many scientists, and would-be entrepreneurs, are hyper-focused on technologies or alleged features rather than benefits because that's what they find most compelling, but the process of determining value, and who might buy a product, has more to do with the Pains and Gains experienced by a potential customer.

Like the Business Model Canvas, The Startup Owner's Manual and Business Model Generation are dry and formulaic. But who am I to argue with success?

By all accounts, searching for a business model is a step-by-step journey of conquering one of the aspects of business development that might be most uncomfortable to those of us who are socially-inept or analytically minded:

Engaging people to validate your hunches about your product.

Software startups must be able to distinguish between users and paying customers because they're not always one in the same.

Stripped bare, Steve Blank's insight is that customer discovery is essential. One personal epiphany worth repeating over and over again for would-be software entrepreneurs:

Don't bother coding anything until you discover & understand who's going to buy it.

If you're attempting to bootstrap a software product or company, The Startup Owner's Manual is essential reading because I'm betting the formulaic practices will save you months, if not years, of misguided effort.

REFERENCES

Business Model Canvas. PDF.
Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers, Alexander Osterwalder.
NSF Innovation Corps. National Science Foundation.
The Startup Owner's Manual: The Step-By-Step Guide for Building a Great Company, Steve Blank.

SUPPLEMENTAL READING

Bottom-Up Change: The Agile Manifesto at 10, Bobtuse Bobservations.
Design Serves Human Purpose, Bobtuse Bobservations
Hypothesis Testing & Software, Bobtuse Bobservations

Shorting Microsoft?

noreply@blogger.com (Bob MacNeal) — Mon, 30 Sep 2013 17:47:00 +0000

Are you short selling Microsoft?

Technology entrepreneur and academic Vivek Wadhwa asks, Can Microsoft be saved?

Wadhwa's PBS article offers a glimmer of hope for Microsoft in its wealth of great people.

"But there is still hope for Microsoft. It has a wealth of great people and great technologies in its labs. They need to be untethered from the central bureaucracy and set free to compete and take big risks. I am not too optimistic, though, that this will happen. I worry that Microsoft will go the way of Kodak, RIM and Nokia -- or even the former Soviet Union -- all of which tanked because they were busy protecting old turf."
― Vivek Wadhwa

As one who has used Microsoft's software development products extensively and almost exclusively in years past, my opinions about Microsoft align with Vivek Wadha's critique of Microsoft's fate.

Perhaps Microsoft will be saved, but it will be a tough row to hoe.

Culture-Changing & Product Focused

Yahoo! CEO Mayer

We all thought Yahoo! was dead, but against all odds, Marissa Mayer is reviving Yahoo! Microsoft sorely needs a culture-changing & product-focused CEO like Mayer.

Microsoft has a busted culture that historically pitted one division against another. Microsoft is also burdened with a shitty stable of over-priced, sever-centric products.

Windows 8? Fahgettaboutit!

Not only has Microsoft been late on just about everything the last decade, they've also lost the software development community. Losing the software development community is one big, sloppy kiss of death. For today's software developer, having too much Microsoft on your LinkedIn profile is a liability that says,

"I'm old school & unmotivated to learn new stuff".

No software product start-up worth its salt builds on the Microsoft tech stack. The price of entry is too high, the tools are insular, and the ecosystems around the tools are anemic when compared to competing tech stacks.

Nuke & Pave?

Microsoft needs the Marissa Mayer playbook. Microsoft's new CEO will have to nuke and pave the culture, then put a laser focus on products. Borrowing from Steve Jobs, the Microsoft product line must be trimmed and profoundly simplified.

Make it Cool?

You don't see many hipsters booting Windows 8 in your local coffee shop do you?

Creating, sustaining, or turning-around a company usually boils down to people and buzz. Underlying and buttressing the buzz are kick-ass products that aid and delight.

One of the questions the new CEO should address is,

How do we win back the software development community?

Somehow the new CEO needs to make it cool to have Microsoft chops again.

Pull Requests for Teams

noreply@blogger.com (Bob MacNeal) — Wed, 28 Aug 2013 10:23:00 +0000

Sunflowers, 1887
Vincent van Gogh

If you recognize a measure of truth in the proverb:

Two heads are better than one,

you will want to experiment with the Pull Request workflow with your next software team.

Pull Request Workflow

The Pull Request workflow, implemented by popular shared source code repositories like GitHub and Bitbucket, is an excellent means to spark team discussions and improve code quality.

Like a classic Greek ode, the Pull Request Workflow has three call & response parts:

Branch;
Discussion; and
Merge

Pull Request Workflow: 1. Branch; 2. Discussion; and 3. Merge

Following is a sample workflow for a hypothetical feature called more_cowbell.

1. Branch

Assuming you have already cloned (downloaded) a shared repository to your local machine, the first step is to create a branch off of the trunk (often called master).

Following are series of git terminal commands that will get you to the point where you can modify code. Typically you will create a local branch from the shared repository to work on a new feature or a bug.

Create the more_cowbell branch as follows:

(master) $ git checkout -b more_cowbell

Then checkout the newly created local branch as follows:

$ git checkout more_cowbell

Think of more_cowbell as your local sandbox. Now make additions, deletions, or changes, then create/run unit tests and integration tests, and commit your changes. Or if you prefer test-first, do the tests first, then commit.

(more_cowbell) $ git commit -am "Add more cowbell"

Finally you're ready to push your changes back to the shared repository for review, discussion, and a potential merge back to master.

(more_cowbell) $ git push -u origin more_cowbell

2. Discussion

Go to your shared repository on GitHub, Bitbucket, or other. Locate the more_cowbell branch you pushed in Step #1.

GitHub and Bitbucket both have side-by-side comparison tools. Use the compare tools to carefully inspect the proposed changes by comparing more_cowbell with master.

When you're ready to open your proposed more_cowbell changes to a team discussion, locate and click the Pull Request link (or button).

Your teammates will be notified of your Pull Request. They will then review your changes, post comments on individual lines of code, or post general comments on the Pull Request. Typical comments might involve issues with formatting, the location of a method, notification of code duplication, suggestions for refactoring, etc.

It is courteous to respond to the comments posted on your Pull Request in a timely and respectful fashion. A concise and courteous response from you following a "you might want to..." comment might be:

"Good catch. Will do."

Some teams use round-robin to determine who reviews a given Pull Request with each developer assuming the role of reviewer. Other teams assign one or more lead developers to review all the Pull Requests. Most teams encourage the entire team to look at and comment on Pull Requests as time permits.

Others may add commits to your branch by doing a fetch and a checkout of more_cowbell on their local machines. They would follow the same workflow of modify, commit, and push back to the shared repository. Presumably more discussion would ensue.

3. Merge

After ample discussion, and perhaps following some additional changes or tweaks that have been suggested to you, someone other than you will merge your changes to master.

Summary

For me, the essence of a Pull Request is:

to learn from my teammates, and
to agree upon what constitutes a worthy addition or an incremental improvement.

Like me, most developers readily agree that code reviews improve quality. And like me, most developers dread the traditional code review because it often means an uncomfortable one-on-one encounter with a high-ranking alpha developer where one is made to feel defensive or worse, incompetent.

Pull Requests feel less authoritarian and more democratic. It is a lightweight quality improvment process more in the mode of discussion and edification, than in the mode of admonishment. It has been my experience that Pull Requests spark discussions about the code and the craft which, in turn, tends to improve the quality of the code.

I'm all in favor of the democratic principle that one idiot is as good as one genius, but I draw the line when someone takes the next step and concludes that two idiots are better than one genius.
-Leo Szilard

References

Work with Pull Requests, Bitbucket.org.
Using Pull Requests, Github.
Effective pull requests and other good practices for teams using github, David Winterbottom, October 20, 2012.

I'm Doing it Wrong? Really?

noreply@blogger.com (Bob MacNeal) — Sun, 14 Jul 2013 18:10:00 +0000

I chafe at how freely many of us will say you're doing it wrong.

Sometimes distinguishing a right way from a wrong way is easy. Sometimes it's not.

Holding a telephone handset upside down appears laughably wrong - unless you're doing a comedy bit (where it might appear laughably right).

The wrong way to produce software is not as obvious as holding a telephone handset upside down.

Producing software involves contextually-dependent variables. We are faced with business constraints, technical hurdles, and inter-personal challenges. Constraints, hurdles, and challenges are situationally-dependent. Constraints, hurdles, and challenges vary from product to product, and change from one environment to the next.

What might have seemed wildly right in one context, might be wildly wrong in another.

Your Dogma Ran Over Your Karma

A post was shared on agile .net practitioners with the title "If you are building applications without writing your tests first then you are doing it wrong. The title was probably meant to attract attention, and the post was probably written in the vein of self-promotion, but it got my attention.

I have benefited from the virtues of Test First, but the statement, "If you are building applications without writing your tests first then you are doing it wrong" seems hyperbolic, naive and unnecessarily dogmatic.

Situational Utility

Test-Driven Development (TDD) and Test-First have become catchphrases. Who hasn't been endorsed for TDD on their LinkedIn profile?

Several developers I know use Test First exclusively. Many more developers I know talk about Test First, but do Test After. Still more developers I know appreciate and espouse the virtues of Test-Driven Development, but rarely use it. Hardly anyone doesn't, at least, pay lip service to TDD.

Developers encounter many different situations. It follows that there are many ways to approach the tasks at hand. TDD is not the holy grail.

Craftsmanship Surcharge

There is at least one situation, and perhaps several more, where TDD or Test First adds a gratuitous craftsmanship surcharge to the bill.

Lets say you are contracted by a start-up to iterate from an initial proposition to a viable business model. Is TDD a cost-saving approach? Probably not. While the code might be flawless, TDD slows down the cycle of testing a business proposition thereby increasing the start-up's burn rate. Many start-ups don't need flawless code during the market testing phase. The reality is that there is going to be throw-away code, particularly in the context of a lean start-up where the team is meant to be in iterative learning mode.

Be Kind, Rewind

Several of the useful things many of us picked up in the early days of XP, and during the maturation of Agile, are too often applied as blunt instruments to pummel our less dogmatic teammates.

TDD can be a blunt instrument. Just like the common misapplication of Stand-ups, Retros, and Burn-down charts, Test First can degrade to an abrasive command-and-control directive as readily as it can prove to be a prudent practice.

The What and The Why

Approaches, practices and tools have a place when they serve The What and The Why. We agree craftsmanship deserves attention. As practitioners we love bullet-proof code. Many of us have gotten proficient at The How and The When.

I'm self-critical. I know I might be doing it wrong. In many cases, I presume to be wrong. But increasingly I don't care so much for The How or The When.

I'm reviving my old mantra: Don't Lose Sight of The What and The Why.

A Personal Approach to Agility

noreply@blogger.com (Bob MacNeal) — Sat, 19 Jan 2013 01:44:00 +0000

I will always appreciate the spirit of the Agile Manifesto. I revisit the 12 principles behind the Agile Manifesto on occasion, particularly after experiencing recipe-driven nincompoops who use the principles as blunt instruments to flog me and fellow developers.

I am also increasingly surprised by how disconnected Conference Circuit Agilists have become from producing software. Pithy anecdotes don't often jibe with in-the-trenches experience.

A Personal Approach

As an itinerant software maker, I enjoy the inter-personal stuff of software teams. I also enjoy the process stuff, but mainly in environments where the process remains in a state of continuous improvement.

Improvement has little to do with output and a much more to do with making software that people like to use. My approach is born from trial and error. I hope my approach remains in continuous improvement. I hope it remains simple.

I try to understand the context of the product challenges. I like to think I have become less dogmatic and grown more pragmatic. I try to be sensitive to the social dynamics of the organization that has invited me in. Some truisms are:

Recognize every product is different - There's no one-size-fits-all in producing software.
Build capital by getting stuff done - There are few bigger chits than working software.

Assuming you have banked some capital with your benefactors:

Protest & respectfully resist process ceremony - Process ceremony wastes everyone's time.
Practice the things that make sense - If it has to make sense, it's always a fluid practice.

My approach is a state of mind, rather than a recipe.

"In the beginner's mind there are many possibilities, but in the expert's mind there are few"
- Shunryu Suzuki

Commoditized Agile

Commoditized Agile is a market-driven, largely failed, money-making machine. It is a prescriptive approach that metastasized from what began as the agile movement. Behind the guise of agile, ne'er-do-wells seized the chance to make a living lecturing people about The Best way to make software.

It's the product of opportunists and lazy organizations.

Lazy organizations, seeking the easy pills, threw money at a state of mind believing it would somehow morph into a prescriptive remedy for unhappy employees and crappy software.

Opportunists packaged prescriptive service offerings and over-featured software products around a set of principles that were probably never intended to be prescriptive.
Organizations seized on something new, so they had to throw money at the something new as proof they were doing it.

Commoditized Agile as troweled out by Conference Circuit Agilists, several of whom couldn't possibly have time to produce software, is mostly snake oil. Commoditized Agile, as represented by a host of crappy software products targeted at organizations who are "doing agile", is poorly conceived.

The lessons are simple. Find a personal approach that's an aggregation of trial and error. Co-opt the best ideas of others. Apply those ideas where they make sense. Deep-six any process with the scent of gratuitous ceremony. Remain skeptical of shiny new things. Get rid of tools that hinder your progress. Beware of charlatans selling snake oil.

"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete."
- R. Buckminster Fuller

Postscript

I've been told in a tweet that this post is a bit cynical. So readers should know that I almost always enjoy the smart people I work with. In fact,

The joy I get from the people I work with invariably outweighs the profound organizational stupidity I encounter.

Simple, Assertive Software

noreply@blogger.com (Bob MacNeal) — Sat, 24 Nov 2012 19:13:00 +0000

Do you want your app to Kick Ass & Call it Love Story? Keep it simple. And make it assertive.

Focus on doing at least one thing right.

Distill that thing to its essence. Industrial designer Dieter Rams advises, Less, But Better.

Whenever I've ruminated on then distilled an idea - whether in the shop or in the cubicle - the distillation is almost always stronger.

Less, but better – because it concentrates on the essential aspects, and the products are not burdened with non-essentials. Back to purity, back to simplicity.
— Dieter Rams, 10 Principles of “Good Design”

Twitter is an example of not overstepping a founding concept of a 140-character micro-blog, then focusing on delivering essentials. Simple idea. Simple execution.

I have grown weary of feature-driven apps. In particular, I am weary of apps that try to be everything to everybody — more so when they miss the mark on the essentials.

Assertive Over Universal

Microsoft Word is the universal remote of application software. It's a work-horse I use almost every day because, as luck would have it, I can efficiently produce documents with it. But I'll be damned if I know what many of the icons signify on the toolbar.

Microsoft Word 2010 Toolbar

Despite a bewildering quiver of options, settings, and features, Word delivers on the essential. If you provide users with a gazillion options, settings, and features, be sure to have the empathy to deliver the essential.

For developers, Nice to Have is the front door of feature-madness. Nice to Have is often a one-way ticket to frustrating software.

The most pleasurable software often seems to have an ax to grind. In the most pleasurable cases, it's a sharp ax. Should your app take sides? The folks at 37Signals think so. I suggest reading their essay Make Opinionated Software. Jason Fried, and others, make the case for assertive software:

The best software has a vision. The best software takes sides. When someone uses software, they're not just looking for features, they're looking for an approach. They're looking for a vision. Decide what your vision is and run with it.

A shining example of assertive software is Ayende Rahien's open-source Document Database RavenDB.

When I set out to build RavenDB, I had a very clear idea about what I wanted to do. I wanted to build an integrated, opinionated, solution. Something that will do the right thing most of the time, and let you override that if you really want to.
— Ayende Rahien

RavenDB is good at one thing - providing lightening fast read-models developers can bind to views. And to my good fortune, Ayende imbued RavenDB with guiding opinions - opinions that rescue us from sloppy coding. For example, RavenDB expresses an opinion about unbounded result sets. RavenDB will let you query for the mother lode, but forces you to override default behavior.

Ayende has well-considered professional opinions and expresses them in his software.

So my new mantra is this:

Keep it simple. Make it assertive.

REFERENCES

Getting Real: The smarter, faster, easier way to build a successful web application, Jason Fried, et. al., 2009.
RavenDB in a Nutshell.

YSOD is the New BSOD

noreply@blogger.com (Bob MacNeal) — Thu, 26 Jul 2012 10:56:00 +0000

Old Paradigm

New Paradigm

In the enchanted land of Microsoft Windows OS and Microsoft IIS, the Yellow Screen of Death (YSOD) has all but replaced the Blue Screen of Death (BSOD).

This phenomena is a resplendently chromatic illustration of a Bobtuse principle:

Nothing in the universe is static or perfect.

Should Designers Code?

noreply@blogger.com (Bob MacNeal) — Thu, 28 Jun 2012 10:41:00 +0000

Bobtuse Honeybee Pagoda

I am an long-time programmer. I have a keen interest in simple design and providing a pleasurable aesthetic experience in most things I build.

Jon Kolko's post code is material: why designers must learn to code got me thinking, and predicting:

Designers don't need to learn to code. The code will come to them.

My Programming Arc

I wrote my Hello World in FORTRAN at the University of Minnesota in the early 1980s. But I started programming in earnest as a Civil Engineering undergraduate in the mid 1980s in the days when fast was turbo.

Today I am handsomely compensated to jerk around coughed up hair balls of client-side JavaScript.

Thankfully I never had to program in machine code. One great programming leap was the advent of commonly used computer languages like FORTRAN that abstracted the complexities of machine code.

Another Great Leap

Alan Cooper in his office
at Cooper in San Francisco

Programming made a quantum leap when Visual Basic 1.0 was introduced in 1991. Visual Basic pioneered drag and drop design for crafting user interfaces.

Visual Basic derived from a form generator prototype developed by Alan Cooper and his company called Tripod.

Alan Cooper put the "visual" in Visual Basic

The visual nature of the new Visual Basic paradigm abstracted the software maker from the underlying sausage.

The Visual Basic leap for occurred after the 1991 COMDEX/Windows trade show. There have been no equivalent leaps since. We're overdue.

The Next Great Leap - A Future for Creatives

Returning to my assertion that

Designers don't need to learn to code. The code will come to them.

I suspect there will be a bright future for creative types. All that's needed is another revolutionary leap in development tooling that will enable designers to do what programmers do without having to know how to code. Someone will abstract the complexity.

The explosion of rich client applications, and all of the attending JavaScript schmutz, is a programming nightmare for cats like me who have known better times.

Today's rich client frameworks and persistence schemes have lots of hoop-jumping complications.

Too much sausage meat!

Take heart, I think tooling will be invented that will put the sausage back in the case.

It is laudable to know the your work environment and the materials you work with through and through. But in the case of making applications, simplification by abstraction is what frees us to be creative.

Already tools are appearing that enable applications to be built without the gratuitous and frustrating hair balls that require the services of a programmer.

So I think the code will come to the designers. Application development will be made visual, gestural, instinctual and intuitive.