Jeff Strickler

Where do I put my App?

Amazon Web Services is a popular choice for technology infrastructure. With many free features available, especially in the first twelve months of establishing an account, it’s a tempting solution for early-stage ventures. Amazon is the established leader in cloud computing. Their services are excellent and cover a range of needs, from deployment to notifications.

But I don’t recommend it to the majority of my clients.

The problem is cost. A typical bootstrapping venture needs:

  • A staging and a production environment.
  • Each environment needs a handful of application server instances and a database.
  • Backups
  • Additionally, they may need services like job queueing, notifications, load balancing, and caching.

While AWS provides world-class solutions for each of these needs, the costs do not align well to the budgets of bootstrapping ventures. For example, I’ve witnessed clients spending between $500-$2000 / month for these basic needs.

Digital Ocean (Referral Link: https://m.do.co/c/0dadc6b18092), Linode, and Hetzner are what I recommend to clients who want to maximize their spend to value. To build out an equivalent small-scale environment on Digital Ocean can be well under $200 / month.

This isn’t to say that Amazon isn’t the right solution for others. If you commit to architect your applications in ways that maximize Amazon’s services, or if you expect truly massive scale needs that give you negotiating power, then AWS has a lot to offer. But, if you are building apps that just need a handful of hosts for the foreseeable future, there are options with more predictable performance and costs.

Product Management is Not Optional

Would you ask your lawyer for advice on customer segmentation? Would you ask your doctor how to price your product? Is your marketing team there to tell you whether to pick python for your next app?

Then why are you asking your software developers to define your product, if they don’t represent your target customer demographic?

One of the repeated mistakes I see in startups / early-stage ventures is that they misunderstand the roles of software development and product management. There is often a further mistake made, seeing the CTO as strictly a senior developer, but we’ll save that for another article. Software development is about the technical design and construction of software, ideally following defined requirements. So where did those requirements come from? Who decided what customer to target, how to price the software, the sales channels, the branding, and the business model? That’s the role of product management.

You, and your management team, in the absence of dedicated product management personnel, must take on these responsibilities in an early-stage company. If you aren’t meeting with prospective customers and honing the set of products or services, including software features, then who will? In the absence of well-defined services and software features, your developers will struggle to deliver the appropriate capabilities. How can they understand the priorities or deliverables if they haven’t been defined?

Software developers are there to act as a counterpart to product management. They have a role to play in finding creative solutions, but it cannot be their responsibility to define the business. Leaving software developers to define the product to be built is a path to failure.

Call Me Maybe

I don’t want to join your Google Hangout.
I don’t want to answer your Slack /call.
I don’t want to accept your Skype meeting invite.
I don’t want to be part of your Workspace By Facebook.
I don’t want to install Zoom, or GotoMeeting, or WebEx, or Join.me, or Highfive, or LyteSpark, or BlueJeans, or RingCentral, or ReadyTalk, or anything else. I don’t want to give my thumbs arthritis texting back and forth.

I want you to pick up the phone and call me. Because the phone actually works.

  • The phone is always within reach, anytime of day, in any location.
  • I don’t have to deal with WiFi cutting out.
  • Everyone has a phone number regardless of their provider.
  • Everyone can choose the type of phone that works for them personally.
  • I don’t have to run software updates before I can join your call.
  • I’m not required to have ten pieces of software installed, none of which work with any degree of reliability, just to “improve communication.”

You want to improve communication? Pick up the phone and call me.

Developer Productivity

Before even leaving her bed, she reaches for her phone to review a dozen emails. On the bus on the way to the office, her phone rings with her boss asking for information he needs for a meeting later in the morning. Once at the office, her office mate, new to the company, catches her with a question that takes thirty minutes to explain. She has maybe an hour until the daily standing meeting, which while scheduled for five minutes, will consume much of an hour between the actual meeting and its fallout. She’ll have maybe an hour after that until she has to decide whether to do what’s good for her health and grab lunch or a workout, or what’s needed to get the job done, IE: stay at her desk. In the afternoon the scrum master drops by for an update, and she spends another 30 minutes updating the Kanban board. Her boss needs a status update before end of business. Then they meet up for a spring review meeting. As the end of the day nears, she debates whether to leave early so that she can beat the commute, or stay until after rush hour and not be home until late.

And you wonder where developer productivity is going?

  • Daily meetings are exactly akin to making quarterly numbers for the street: short-term lies designed to appease stakeholders. They interrupt focus and incentivize the perception of productivity over reality.
  • Communication tools like Slack and email can be incredibly productive, but much like shiny objects, they cause context switching and loss of focus. Rather than demand developers be responsive 24×7, instead encourage them to set aside specific time to answer email and specific time they are willing to be responsive to chat messages.
  • First published in 1987, the lessons of the book Peopleware still hold true. Context switches, such as casual interruptions, consume a multiple of the interaction time. Keep these to a minimum and encourage team members to respect each others need for concentration.
  • Project management tools are useful, but their overhead must be balanced against that usefulness. Encourage greater automation and don’t let matrix management overwhelm your team.

Cargo cult science, a phrase first used by physicist Richard Feynman, describes practices that have a semblance of being scientific, but in fact are misunderstood ritual. The original Agile Manifesto emphasized teams embracing practices that worked given their specific circumstances, but have been misconstrued into cargo cult behaviors. Productive teams will get back to basics and do the things that work for them, rather than blindly following fads.

Do I need Docker?

Docker (https://www.docker.com) is a container technology that has gained significant adoption and used frequently as a synonym for containers, DevOps, Continuous Integration and Continuous Delivery. I assert that for the majority of environments, it adds an unneeded layer of complexity.

Let’s use the same criteria Docker uses to describe their benefits.

Cost Savings

Startups in particular seek to take advantage of low-cost opportunities like Amazon Web Service’s free tier. At the specification of an EC2 micro instance, it’s unlikely you’ll be able to run more than one instance of your application, so the proposed cost savings of resource maximization proposed in Docker is moot in those cases. Free outweighs any micro-optimization cost savings.

For enterprises with established virtual machine infrastructure, the cost savings is also questionable. These organizations have typically developed deep expertise and have optimized their investment over many years. Growth is also typically predictable, meaning that if their application ran within a particular footprint last year, it’s unlikely to need significant shifts.

Security

If someone gains access to the underlying host, containers aren’t going to help with your security. While it is true that some categories of attacks might be, pardon the pun, contained, by the container, in the bigger picture of security it isn’t enough alone to justify containers.

Portability

Ask any team developing on Macs and deploying on Linux how well Docker is working for them. For that matter, show of hands here who has ever run into problems building or running Docker images, even in like-for-like environments. Portability is certainly one of the promises of containers, but real-world cases don’t demonstrate consistency.

Agility

Before Docker: Add dependency, keep developing.

After Docker: 

  • Identify needed dependency
  • Find team Docker master to build new image
  • Debate merits of adding dependency
  • Alert everyone on the team a new image exists
  • Everyone has to update to latest image

Point being, agility is more dependent on the rules and processes of the team than on the technology.

Continuous Integration and Delivery (CI / CD)

CI / CD should be on the agenda for every team. That stated, Docker itself is not a prerequisite or even a requirement to do CI / CD. It’s not even clear that it makes it easier.

Microservices

Microservices are an architecture choice, not appropriate for every environment and application, and certainly do not require containers.

So, if you are needing to bring dozens or more instances of your application up and down rapidly and on the regular, then containers, and Docker, might be part of your solution. If on the other hand you are like most organizations and your application’s profile is such that it expands in predictable ways, containers are just another layer of technical schmutz. Even for the case of creating predictable developer environments, the application dependencies are typically a more significant problem than the environment itself, but there are also alternative tools for solving that scenario.

Palouse Falls

Palouse Falls is the state waterfall of Washington state and an impressive site. Worth a visit if you are in the area.

There are a number of these signs and it’s highly recommended you observe the warning.

Palouse Falls is about a 90 minute drive from Spokane, Walla Walla, Pullman, and the Trip-Cities.

Minam Lodge

The new Minam Lodge (http://minam-lodge.com) opened this summer. Options for getting there include flights into its private grass airstrip, horseback, or an eight mile hike. The trip in on foot is a descent of more than 3000 feet. Definitely worth a visit.

Barn is being renovated into an event space.

Much of the menu is grown on site in the garden and greenhouse

Fishing, swimming, or just sitting by the river makes a great day.

Multiple lodging options exist. The tents are secluded and have comfortable beds like the lodge rooms.

The teepees come with mattresses on pallets and share the showers and toilets with the tents.

Cabins and the lodge rooms have custom built furniture and finishings.

Red’s Horse Ranch is about a half mile walk from the lodge. Lots of stories about its past.

Chimney Lake

A 5.2 mile hike from the Bowman Trailhead. Steady 4% grade. Good huckleberry patches around 6100 feet. Multiple established campsites along the way.

Crossing Bowman creek. Depending on the time of year, this can be knee-deep.

Great views toward the Hurricane Divide.

Laverty Lakes.  In some ways it is prettier than Chimney Lake, but the two established campsites are right on the trail.

Impressive boulder field between Laverty and Chimney.

Chimney Lake from the west on the way to Wood and Hobo lakes. Many established campsites available. Mosquitoes were not a noticeable problem in mid July.

Wood lake is off in the distance another two miles, with Hobo and Bear lake to the west (left). Impressive amounts of snow for the time of year. There was at least one rock cairn, but trail could not be seen.

Aneroid Lake

Six miles, rise of 3000 feet. Trail heavily worn by horse traffic, day packers, and trail runners. Nice meadow and campsite opportunities at the 4.6 mile mark. More people than mosquitos so arrive early or miss out on a good campsite at the lake.

IMG_2439

One of many varieties of moths and butterflies seen on this trip. Raspberries were ripe or nearly ripe, huckleberries were 1-2 weeks gone.
IMG_2480

Legore Lake

Highest lake in the Wallowas at 8957. Trail from the Hurricane Creek trailhead to the cabin is poorly labeled, 6% grade, but clear. From the cabin, trail is straight up the hill, but easier route is to go right toward the creek and then to the boulder field. Trail disappears in the boulders, but proceeds through them along the creek. Above the boulders trails to lake and to Sawtooth Peak are clear with some imagination. Approximately 4 miles each way, 4,000 feet of elevation gain.

legore

IMG_2128

Joe Legore’s Cabin:
IMG_2068

The Red Cloud Mine:
IMG_2235

Moth:
IMG_2237