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.