DEV Community: LoadUp

Ch 7 and 8

Nico Roulston — Fri, 28 May 2021 13:28:04 +0000

CH 7 Bets, not Backlogs

A slight sigh of relief passed through the room when we said there will be no more backlogs. To some this might be blasphemy to others it might be one less list of things they will never get to.

At Loadup we land somewhere in between where our backlog gets some love, but it definitely has items that will never get done. For the most part ours may be different because the backlog is partly between a decentralized list, and a backlog. The decentralized list idea brought up in the book puts the responsibility of keeping track of important ideas that might still be important when we have time to get to them. Instead of offloading that responsibility to someone who might not see the value of the project you hold on, and potentially champion your project when the time is right.

Really important ideas come back to you.

Chapter 8

Well this turned into a doozy of a conversation. That now seems to be a fortuitous precursor to the direction our company is heading(I'm writing this post a week later, so I get the benefit of hindsight here).

The conversation mainly revolved around the benefit or lack of benefit that would happen if we were able to implement some form of cycle for our work. What it boils down to is the idea that measuring developer efficiency is a weird cross between shaking an 8 ball, rolling some bones, and spreadsheets; all wrapped up in the name of effective planning. Now I know that isn't entirely true, and that the answer is out there somewhere. Yet if you are fine with that kind of ambiguity there can be some benefit that comes from some kind of structure/schedule to how the entirety of the development process works. On a side note you should check out the research article by Microsoft ala Github on a framework for measuring developer productivity. The Github blog talks a bit about how they used it, and has a neat Slackbot to help you improve your developer efficiency and happiness.

One thing that has been brought up numerous times is that Basecamp is a different company, provides different services, and thus we can't just copy what they do. I bring this up because in the chapter there is almost a blase approach to bugs. There are caveats that important bugs will halt the presses, but nonetheless a bug is a bug and can be dealt with six weeks from now. At LoadUp almost every bug directly impacts our revenue flow. Now of course we could take the time to have someone look into each bug, see how often it is occuring, and make the decision to fix it or not. In that time frame we could lose a lot of sales instead of immediately beginning to work on it. One thing we all are leaning towards is having someone available for bugs, bug duty, extermination time, etc. This way we all aren't watching the channel and being distracted by any level of bug.

That's all for now. There is a can of worms waiting for conversation. Hit up some comments if you want to discuss.

4,5,6 Shapeup: The verbiage has infiltrated.

Nico Roulston — Thu, 20 May 2021 13:19:54 +0000

It seems like we have come to a milestone in the weekly book club. We finished up Part 1: Shaping, and the verbiage from the book has infiltrated our daily language. I wouldn't say this is necessarily a bad thing, as we all now have a shared language to communicate our pain points, and our successes.

Chapter 4 Find the Elements

I'll be frankt, and say that the discussion for chapter 4 Finding the Elements wasn't invigorating. That isn't to say it isn't a valuable read, but for us it was an easy thing to say this makes sense.

The main concepts to understand is this process is a piece of time that we made the decision to invest in starting the shaping process. It doesn't mean we have committed to the idea, it just means that we evaluated the idea and said that it was worth our time to even begin to explore it in a rough way. All of the other steps can be interchangeable to work with how our teams function.

Chapter 5 Risks and Rabbit Holes

"As shapers, we’re thinking less about the ultimate design and more about basic quality and risk"

Have you ever worked a feature or ticket that has multiple pitfalls, rewrites, or blockers? In chapter four we got a rough outline of the feature, but here in chapter five we start to poke holes in it, and dive down the rabbit holes. They give a great example as to why you want to do this before the process. What it comes down to is we only are working this feature because we think it is a valuable use of our time right now, and it's value is directly tied to the amount of time we are willing to work on it. If we begin to work a feature and the timeline expands is it really worth it in the end?

A huge stand out for our team, even outside of the shaping process, is declaring items out of bounds. These ideas and features are nice to have, but the continual add on either means we didn't plan well enough, or we are adding nice to haves. Nice to haves are valid, but as extra features if we can get to them, and then backlog items.

Chapter Six The Pitch

The last chapter in Part 1 sparked an overall discussion on our team of how this could be valuable for our team.

The most vigorously debated topic was the idea of how would implement this without violating our teams core belief that measurement of work output for developers for measurement sake is a waste of time. There was one positive to the measurement of work, and when it is done correctly it allows the business side to understand how long things are going to take. The caveat to that is when you measure work output correctly it doesn't increase the efficiency of the developer. Now when you measure it wrong developer efficiency is still the same, but "Having numbers that aren’t real causes us to have a false sense of security, and then we make huge decisions based on those fake assumptions."

Regardless of implementing an accurate measurement system the team walked away wanting to try either the entirety of the Shapeup process, one fell swoop and we are doing a new process, or to figure out how to work the ethos of more shaped work before our fingers hit the keyboard.

Any kind of shaping process has the benefit of increasing the effectiveness of the developer, if done correctly. Having a source of truth(something like a pitch) for all decisions allows stakeholders to know what is the plan moving forward with a feature. Addressing complicated logic in that feature becomes a snapshot that developers can go back to when looking at past features and it helps the developer offload their mental ram. When you discuss something in person multiple people may need to know about the discussion, or fast ideas and hard decisions were made but not written down. As a developer keeping that all in our mental ram is difficult, as a stakeholder keeping that plus everything else is difficult.

Me personal thoughts on Part 1.

While reading the book it is starting to feel like this is a recipe for operational success. We are growing and evolving as a company and just like the founder can experience the founder problem, our processes may get stuck unless we figure out how to evolve with the companies growth. This isn't just top line growth, but also employee tenure, the transition to a hybrid workforce, and the increase in new developers joining the team to name a few.

In my mind getting a process of business planning that takes mostly synchronous communication, and moves to using asynchronous communication is a must for us going forward.

Signing off for now, but hit us up in the comments with suggestions for the transition, questions on our thoughts, and discussion for how to become a little better.

2 Week bookclub recap

Nico Roulston — Mon, 26 Apr 2021 15:50:33 +0000

Chapter 2 and 3 of ShapeUp recap.

What a difference a single chapter makes. In the past two weeks LoadUp Engineers have discussed Chapter 2 and Chapter 3 of ShapeUp. As a team we went from ending our discussion of Chapter 2 wondering how can we apply this 'shaping' thing to our process of ticket creation , to embracing the idea of 'shaping' our own shaping process. I know it's redundant, but it is what we are doing.

CH. 2 Principles of Shaping

The Principles of Shaping ends with a great synopsis of steps to shaping.

Set boundaries. First we figure out how much time the raw idea is worth and how to define the problem. This gives us the basic boundaries to shape into.

Rough out the elements. Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.

Address risks and rabbit holes. Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.

Write the pitch. Once we think we’ve shaped it enough to potentially bet on, we package it with a formal write-up called a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at kick-off to explain the project to the team.

As a team we weren't excited about the process yet after reading this chapter. We talked a lot about in our past experience the pain of having project requirements and wireframes that were too concrete. From the developer perspective being handed a picture perfect wireframe extended project timelines, and potentially led to poorly written code. Being handed the right level of detail that allows the developer to come up with a better fit solution brings a product to the table faster, and generally is more maintainable. Something none of us had encountered was the idea that a designer being handed work that is too shaped will have a hard time creating something innovative.

On the other side of things not taking the time to have a process that 'shapes' the work is equally a timesuck. On our team we err more towards the not shaped enough, and also don't have a strong foundation of who should be 'shaping' the work. This style of development is exactly what a startup needs. We are lean, agile, and work with Rails. In other words we get a lot done quickly. Fortunately we are growing out of the start up phase, and we are starting to look for the efficiencies we can gain by making sure our processes are fine tune. Just today we broached the subject again of specialization of tasks. I know it's corporate to think like Henry Ford, but it is true to nature that context switching, task switching, and in general jack of all trades is not as efficient as someone who specializes. The key is figuring out is it worth the investment cost to buy the new machinery when your current machinery can get the job done, albeit a bit slower.

If you are still reading I'm not going to talk about the idea of having two tracks here. It is mentioned in the chapter and we had an advocate for why this was important, but it wasn't until Chapter 3 that the team organically arrived here.

CH. 3 Set Boundaries

Drum roll, Light bulbs, and Developer teams making magic!

What a difference a single chapter, and single discussion can make. Really though we haven't changed anything yet, so did it really make a difference. As time progresses we will see if as a team we can begin to set Boundaries. The idea of not saying yes to a project right away, and taking the time to really understand it sparked rapid discussion that I will chronical for you.

We can now ask better questions
By slowing down the process and setting a boundary as to when work is ready to start development we can ask better questions. When handed a task that isn't fully complete the looming deadline can prevent us from asking the right questions to really figure out what is needed.
Two tracks comes back!
The idea of two tracks was talked about in the last chapter. Shaping of the work is completely separated from the actual development and design work. It was during our discussions of asking great questions, and discovering what the process looked like to do so that we ended up organically arriving at the two track concept. In our past we always had our developer mind on when asking questions, because we were thinking about our developer tasks. As Riaz put it we really need to be thinking more like a therapist when being asked to perform certain functions.

Case in point. The user(wife/husband) comes to us(developer/therapist) and says that the program(wife/husband) isn't doing the task it's supposed to be doing. Now at this point as a developer we start looking for bugs, checking the code, and coding out a solution to their pain point. The issue here is that the pain point ultimately was the the user wasn't communicating their needs to the program correctly. As a therapist you ask the questions of the surrounding situation. How was the user acting that day, what was the actual thing they were doing. This takes a different mindset, and is hard to do when context switching between developer and therapist. In the end it turns out that the User was doing something that could be automated and the solution written was a better long term fit.

Time Box the solution by it's value This one seemed to be a switch flip in our minds. Start the shaping process by asking how much time are we willing to invest in this idea. Really the question needs to be asked twice. How much time is it worth to shape this idea, and how much time is it worth to develop the idea. With those questions answered you can then ask what my opportunity cost is and begin the shaping process when it works for the company. The beauty of separating the two questions also separates the work. We now can work on development when it benefits the company. The shaping and development don't have to be coupled to each other anymore, and we can pivot our development epics based on new ideas and requirements.

The amount of time you are willing to spend will also change the solution that you are going to put out. If you have all the time in the world you will have the most feature rich, and probably bloated solution. If you are timeboxed you will only put in exactly what needs to get done, and can evaluate if the solution solves the issue or needs to be evaluated in how much time it is worth.

Lazy Evaluate like Functional James gets credit for this one. Taking the idea of a project being ready to develop and equating it to lazy evaluation. We have all these requirements and inputs and will start gathering them, but we won't start work until we have all the inputs our function requires. To us this means we can have the function of development waiting in the background as it is being fed inputs. Once it receives all the inputs required to start work it fires off and the development process starts.

The ultimate question at the end of this chapter is what are the required inputs to our lazy function? As a team this is something we are figuring out.

Stay Tuned, and as always we love the comments, questions, and discussion.

We stream video games, should we stream websites?

Nico Roulston — Wed, 14 Apr 2021 14:26:31 +0000

There has been this rolling ball on a downhill slope of evolution bringing us towards streaming websites. The question is will we actually do it?

If you keep your thumb on what the Rails community is doing you will have seen that they are pushing forwards with the ability to live stream updates to the dom. Rails 7 will officially include HOTWire(HTML, Over, The, Wire) a baked in solution to bring the amount of Javascript you need down to what they lovingly call a sprinkle amount. Rails can't take all the credit, Liveview has been out for awhile, but they just might be the ones to move an industry away from SPA frameworks.

Before Rails brought in Hotwire if you were tenacious enough you could use ActionCable, a baked in rails websocket solution, to create a chat application. Then came the makers, who built the AnyCable, CableReady, and StimulusReflex libraries.

So why has the revolution not begun. Google Stadia streams video games, Pluto streams a multi tenant ecosystem for VR. This is literally pixels being streamed to the client and yet as a web developer community our crud apps aren't able to do the same thing. I really couldn't tell you why the community hasn't done this but I can tell you what we at LoadUp think.

It comes down to the amount of work needed to implement a solution. What is crazy is that somehow we have ended up in a position with SPA's that requires an exponential amount of work and complexity over the webpages of yore. The thing is the User now expects this kind of workflow, and breaking away from user expectations is what influencers are used for. I digress though.

Even taking into account the expected customer experience, it is more work to write an SPA then it is to drop in the aforementioned libraries into a rails build. Here is the kicker; you can't just drop in the libraries. In the working world you already have a functioning app, and most likely it isn't small in size. Getting it integrated is a lot of work, and isn't worth the effort to replace React/Preact/Angular.

The decision is a simple calculation of team size, budget, time, complexity, actual dollars it generates, and code base size. Simple right.

We have high hopes at LoadUp that around the corner Rails will have developed the drop in solution that doesn't require a codebase overhaul. They did with Stimulus, you can insert it just where you needed it in your current project.

As always we would love to hear your thoughts.

P.S. I know I missed out mentioning every library that has pushed this idea of streaming SSR updates, and would love if you put them in the comments. Most likely there are a lot I have not heard of.

FactoryBot sidecar associations

Nick Bell — Fri, 09 Apr 2021 02:06:00 +0000

The problem

Often, we create "sidecar" models alongside "primary" models in Rails apps. For instance, if you're developing a blogging platform, you may want to create the user's blog model when the user signs up. An example set of models:

class User
  has_one :blog
end

class Blog
  belongs_to :user
end

class UserCreationService
  def self.call(user_attrs:)
    user = User.create(user_attrs)
    Blog.create(user: user)
  end
end

This works great in production, since we always run that service when users are created. However, when testing we might not want to use the service in every spec that requires a user. This is where a fixture/factory setup comes in.

Now, when testing your app in RSpec, I've found the ease of building models with FactoryBot to be a much better development experience than using Rails' standard fixtures. To build a factory for these, you might do something like this to start:

FactoryBot.define do
  factory :user do
    blog
  end

  factory :blog do
    user
  end
end

Then, in your model specs:

describe User do
  subject { build(:user) }
  it { is_expected.to be_valid } # i.e. have a valid factory
end

describe Blog do
  subject { build(:blog) }
  it { is_expected.to be_valid }
end

However, running these specs will give you an error like this:

SystemStackError:
  stack level too deep

This happens because FactoryBot doesn't know that, when calling build(:user), (which calls build(:blog)), that the user is already present to be attached. Therefore build(:blog) will just call build(:user), and so on, creating the infinite loop.

The Solution

To fix this, we need to specifically assign the sidecar model to the primary, and vice versa, in the factories:

FactoryBot.define do
  factory :user do
    blog { association :blog, user: instance }
  end

  factory :blog do
    user { association :user, blog: instance }
  end
end

This will properly associate the 1-1 models whether you call build(:user) or build(:blog). You can even still use an override attribute to create a model with override attributes.

2 examples, 0 failures

Hopefully this helps. This should be one of many tiny tidbits.

How do you bookclub?

Nico Roulston — Fri, 02 Apr 2021 21:49:24 +0000

We would love to hear your thoughts on what you do to share knowledge with your team.

Here at LoadUp we had our first developer book club today. First of all this isn't just a bookclub, but an avenue for us to [pod, parking lot, table, hold off on talking about an interesting topic until an assigned time during the week to discuss in depth] any kind of knowledge that we think will benefit the team, or is worth exploring in depth.

Here is how we currently run our 'book club'

You don't talk about bookclub
You get a week to read the book chapter
Anyone can add other knowledge avenues they would like to share and they will be discussed in a FIFO manner
We try to ask two questions: 1. How does that differ from what we do now? 2. What could we use?
Most importantly no topic is off the table - radical ideas change the world.

Like all things that are new we started with an idea and came out the other side with something different. Next week we may end up changing how we do this because this thought experiment will evolve.

Why is this important to us?

As a growing team we will be constantly in the storming, forming, norming, and hopefully performing stages of team dynamics. These discussions will help our tribe through each of these constant evolutionary stages as we grow as a company.

Not only will this help our culture it will help our developers to push the boundaries of their comfort zones by learning new things, learning to speak their mind, and navigate passionate discourse. We never should stop learning, but we stop learning when things aren't interesting anymore.

I leave you with this tidbit of random knowledge that came into our conversation today courtesy of @jamessral

Code is a translation of what people do into machine language. It is perfectly legitimate to go the other direction. Shapeup is like an interface that we can interact with, but how we implement is up to us.