Women on the Rise

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

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

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?

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:

• Minimum Viable Product;
• Interaction Design;
• Continuous Integration, and
• Continuous Delivery;

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

Software developer testing with JUnit

Ten outsourcing considerations when choosing a software development team:

1. Are they local?
2. Are they recommended by someone you trust?
3. Are they demonstrably adept in DevOps (Continuous integration, Continuous delivery, Product stewardship*)?
4. Are they tech-stack agnostic?
5. Do they have collaboration chops (Pair programming, Pull requests, Distributed version control system)?
6. Are they hip to quality considerations (Interaction design, Test-driven development, Test automation)?
7. Are they a learning organization?
8. Do they have soft skills?
9. Are they product-centric rather than project-centric?
10. 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?

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.