Design moves down the stack

Written by on

The purpose of design, is to solve problems. Yet when most people think of design, we still think in terms of visuals, not functionality.

It's easy to do this because a lot of the time, those who have solved usability problems in an elegant way, have also worked hard to create visually beautifully interfaces. But it would be a mistake to think that function is born from beauty.

I do think though that we can say beauty is indeed born from function.

One of the things I've noticed about the people and companies I admire the most, are that they treat design as much as a programming/functional/build problem as much as they do as a visual problem.

When I say design moves down the stack, I mean this in both small and large ways. 'The stack' can mean anything from a programming framework, to a computer network, to an electrical grid.

Some examples that come to mind:

In each of these examples, we see design moving further and further down the stack, and I can only see this trend accelerating.

What this means in terms of impact, I would imagine, is that design and engineering will become so closely intertwined that it will be almost impossible to separate the two. And even if you could, there wouldn't be much value in doing so.

What I particularly like about looking at design in this way though is that it can help identify opportunities and hurdles alike, which can in turn be used as a guide.

Take Comcast as an example, a company we all love to hate. One of the things they could be doing, is trying to figure out how to make their own hardware obsolete. Their design could move down the stack by allowing you to subscribe to their service just by downloading an iOS app.

Interestingly, Netflix is now competing with Comcast (and HBO, Showtime, etc.) by moving their design down an entirely different stack. Not a technology stack - which they already have - but a content stack. They now make their own TV shows.

The other nice thing that comes with thinking about design in this way is that it opens up opportunities for all of us, even people who might not consider themselves a 'designer'.

Because we all have our own world-views and sets of problems, we can all find design direction by looking down the stack.

Podcast Episode 14 - The fantasy dies when the marketing begins

Written by on

Well I'm giving another go at bringing the podcast back! We'll see how it goes. In this episode I talk with my good friend Ryan Evans, the founder of Lift Marketing and BiteSizePR. Both companies help small businesses get marketing and in this episode we talk about building products, marketing them and why so many people put off marketing and sales for so long.

Subscribe to our podcast in iTunes, or listen to it below!

 

Milestones and how CodeClimate helped us reach them

Written by on

Goals are your lifeblood.

If you don't pick a destination, you'll never get there. Even if you have a map, you'll never find your way. You have no target.

A few months ago, we started using CodeClimate. We knew we had some bad code, and bad code comes in many forms.

Some code was just dusty. We hadn't touched it in over a year. As we all know, you learn a lot in a year. If you think code you wrote a year ago is still great, you probably haven't learned much.

Some code was poorly designed. It was a tightly coupled mess. We've written about this recently on how you should opt into your business logic. Tightly coupled pieces of code will cause you to pull out your hair. Avoid it at all costs. You should check out Ruby Science if you currently feel this pain. It's a great eBook written by thoughtbot which we used to further train ourselves into thinking about code in a better way.

CodeClimate helped us set the goal. It gave us a destination. When wet set our goal, our GPA was 2.5.

At first, we were slightly depressed that our code base received such a terrible score. A few bad classes and bad practices were pulling our GPA down. After all, our code base was almost two years old - and every code base incurs technical debt at some point. With client work, it was debt we couldn't always pay back.

When wet set our goal, our GPA was 2.5.

Don't be like us and get depressed. Many of our favorite code bases have relatively poor GPAs. ActiveMerchant is stuck at a 1.7 GPA right now (although this also includes many third party gateways). Discourse is a 2.8. Paperclip is a 3.1. Rails is a 3.4. Devise is a 3.5. Rails and Devise are pretty damn good.

These aren't amazing 4.0 GPAs like you might expect. Every code base has some parts that are complex.

We set a goal of 3.0. It was achievable in the short term (within a few months). It wasn't unrealistic (like 4.0).

To achieve that goal, we did a number of things:

  • We stopped the bleeding. We stopped allowing any questionable code into our code base. We were very strict with this. No longer were we shipping things and saying "we'll come back to this later."
  • We fixed broken windows. Anytime we were adding a new feature or fixing a bug, we'd refactor.
  • We started having weekly technical discussions with our engineering team. We'd talk about accomplishments over the past week and we'd prepare examples for all of us to talk about and work through.
  • We took some risks and aggressively refactored with proper unit tests. We took the time to extract important pieces of our application into smaller, thoroughly-tested units. This was risky in we were refactoring payment processing and handling of student credits.
  • We collected momentum while watching our GPA rise. We did not tolerate decreases in our GPA, only increases.

As it stands today, our GPA is 3.21 and rising.

We've eliminated numerous code smells. We've properly extracted business logic which transformed F classes into A classes. We have better test coverage for the important pieces of our application. The application is more stable overall. We're not afraid of breaking anything. Classes are better loosely coupled. We've eliminated most ActiveRecord callbacks (and I recommend you eliminate yours, too). Avoid callback hell.

As you can see in the charts above, we still have some work to do. There are still some hairy spots. We still have problems. We work everyday to make our code better as should you.

There's no reason to get depressed though. After all, the most important metric for your product is: Do your customers find it useful? These scores don't mean anything if your product sucks and nobody uses it.

However, improving your scores pay dividends down the road.

  • We're reducing complexity. It's much easier to jump into the code base and understand what's going on.
  • We solve bugs more quickly.
  • It's much easier to refactor for a number of reasons. We have simpler tests. We don't rely on the database much for testing since our business logic is composed of small, simple Ruby classes.
  • We can expand upon existing functionality easier. Things are no longer tightly coupled. If we want to reuse something, it's pretty easy to use it in another place.
  • Our developer happiness has increased. We don't have to work in a shitty code base anymore. Watching our GPA improve is a big boost to our confidence.

We've had some fun over the past few months improving our code. I hope you find this advice useful and start using parts of it in your own teams. Let us know how we can help.

CodeWars shows you there are so many ways to write code

Written by on

As a team, we've been playing around with CodeWars.  CodeWars is a great way to learn the basics of writing code. They currently support Ruby, JavaScript, and CoffeeScript. We've had some fun with it - discussing the best solution to each problem as a team.

While CodeWars is fun, my favorite part is completing a solution and comparing your answer to the many other answers people have submitted. It's such a great way to learn and you remember where you've come from. You might tell yourself, "I remember when I would've written code like that" or "That's interesting. I never thought about it that way." 

This is completely different from StackOverflow. StackOverflow encourages one accepted answer. How often do you Google for a solution and simply look at the accepted answer? After you work the problem out yourself, CodeWars makes it really simple to scroll through other solutions by real people. 

Here's what I mean. I pulled a few examples for you. I've also given my reaction to each solution. 

Complete the keysAndValues function so that it takes in an object and returns the keys and values as separate arrays.

Simple sort, but this time sort regardless of upper / lower case.

That's why I love CodeWars. I'm not sure if signup is open to everyone, but if you need an invite, let me know. 

The ingredients are not the recipe

Written by on

Take any can of Coca Cola, and the ingredients are right there on the side. 

But the recipe is famously secret.

The same holds true for companies and organizations. The ingredients might be everything from the computers and software you use to the various positions that people fill.

But it's the recipe that matters.