Get trending design toolsGet weekly design tools and news
We all remember when the 2nd one happened. Back in 2007, Steve Jobs famously started...
I have a hunch that once people saw the economic potential of software, they started looking for ways to “scale it up” and we haven’t stopped searching yet.
There is something peculiar about software that makes it different from other crafts. A long while ago, I read “The Mythical Man-Month” by Frederick Brooks and I think he called it accidental complexity. How is it that we’ve found ways to organize the work around so many other creative disciplines but writing software is still hard?
What do I mean with hard? Things that would take yourself maybe a couple of days to do in a way that sort of works become projects that span months or years in the enterprise. And with enterprise I mean startups that can have as little as 50 software engineers. But I’ve also see much much worse.
A very senior leader at a company once told me that all big companies operate like this and that the big ones “can pull it off.” With “like this” I mean central project management, migration projects that take months to complete without little obvious customer impact. The mental image I get is Napoleon shuffling around his troops on some hills. He needs to have the cavalry up front, but first he has to move that unit across the river, but before that can happen three other units need to be moved around, and so on. Sure, it can be done (like Twitter infamously moved away from Monorail), but it is hardly fun nor does it look like a good use of everybody’s time and money.
It is interesting that I was thinking of the military at all, but that’s just the way the mind works, right? And we’ve seen many other metaphors for organizing the work to write software “at scale.” There’s the waterfall, a kind of top-down approach that is inspired by engineering projects. Brooks himself suggested a surgeon’s team as a better metaphor. Agile software development doesn’t have an explicit metaphor, apart from it being a bunch of people essentially (“people above processes!”). Don’t ask about SAFe.
I find myself coming back to the film business, because it is also an activity which has both a high degree of creativity but also a lot of specialization (anybody really knows what the “best boy grip” does?). They also had a couple more decades to figure it all out, so maybe that’s what’s missing for software development.
Now, what’s so special about software development? Somehow it seems to be an activity that benefits a lot from being done in one mind (as exemplified by this comic). Somehow, the code in front of you is just the tip of the iceberg of a lot of mental representation of what is happening, and it seems that even given the best intentions, you sometimes need to switch it all up and rewrite the whole thing (don’t do that, unless you must, of course. At least do it quickly).
As soon as you start to involve more than one person, you can either try to have them all work on the same mental representation (like in pair programming), or you need to introduce some restrictions on the area of responsibility, so that everyone can mind their own business, or at least work more independently.
Another book I’ve read a long while ago is called “Notes on the Synthesis of Form” by Christopher Alexander, and if I remember correctly, one of the main insights was that whenever you need to design a system against many constraints, things get exponentially easier if you take problems one piece at a time (I’m paraphrasing of course). So that’s a good idea, right?!
The problem is that by breaking down problems into parts, you severely restrict the solution space. If you do it wrong, the right solution depends on two different part doing something that may not make sense if looked at in an isolated fashion.
For some types of programs (e.g. webservices) we found ways how to structure them to make work easier, but often when you’re writing that one software system that will power your startup and move you into DECACORN domain, you might only figure out halfway through what the best approach is, and if you don’t have the guts to clean that up, you’ll in fact end up with a divison of (mental) labor that does not work without oversight, and that means software architects, program managers, and frequent check-ins.
This separation of work happens every time you decide who works on what within a team, but also once you define teams in a company. This will have very real effects on the software you write, also known as Conway’s law. The book “Team Topologies” by Skelton and Pais (recommended to me by Daniel Trümper) takes this insights and applies the “reverse Conway maneuver” by designing the teams in the way you want the system to look like. But still you need to know how that should look like.
Agile software development proposed a powerful tactic, and that is to write the simplest thing that will work, and then refactor (that means cleanup) you code base constantly. There are books (another book I read a long time ago I realize now was “Refactoring” by Martin Fowler) that talk about refactorings, but these are mostly smaller changes like moving fields in classes where they belong (I’m simplifying!)
At this point it has become pretty clear to me that “writing software at scale” is not a question of effort or will. No amount of “move fast and break things” alone will help you achieve that (and yeah, I know they changed it to “move fast with stable infrastructure”). The way we structure software and teams is very real and will constraint what any single engineer or team can do with what amount of work to be put in.
The metaphor I find myself going back to is that of a city, and I first read about that in the book “Connected Company” by Gray and Vander Wal. Cities are remarkable because they are often quite old. They almost seem immortal even if they have been rebuilt and remodeled over the centuries or decades and are constantly changing.
Cities can be thought as platforms for human activities. They provide basic infrastructure like roads, electricity, buildings, shop space you can rent, and now Internet. Some of these pieces of infrastructure change very slowly (like roads), while others are much more flexible, like the way apartments or shops are used.
What if software were built in the same way? What if the core parts of our business would be like streets, and all that newfangled stuff is something we could build on top, experiment, tear it down if it does not work? I’ve seen a few e-commerce companies from the inside, and while their systems are marvel of technologies able to handle thousands of transactions per second, it does not feel like this, but things like the app and the website are very deeply entangled with the rest. Even if you wanted, you couldn’t create a completely new app or website.
Conversely, if we built our cities the way we build our software, you would need to enter the shop through the special garage, and exit through the roof to walk a wire to get to another custom made building from scrapped containers to do the checkout. And some of the windows are just painted on because they’re an MVP.
We’re trying to make that work with platform teams that are like the electricity companies in the cities that provide commodity services so that not everyone needs to run his own Diesel generators in the basement. This is a good first step. But often, the platform teams are trying to cater to too many disjoint “customers” (like a deployment infrastructure for both backend services and data scientists), and we remove incentives to make it right for the customers by making the use of the platform team mandatory.
Cities are also remarkable because there is only limited central control. Shops open up if they see a market and close if they don’t have enough business. In comparison, most companies are run in a much more top-down fashion, leading to the wrong or not the right decisions being made.
At least, building a new project within a company should be easier than starting from scratch, but my hunch is that many companies fail that test.
As you might have realized by now, I only have pointers, no answers. We’re still not there. Maybe in 50 years we have found the right roles, the right ways to structure teams, and the right approach to architecting software “cities” that are fun to live in.
Till then, my recommendation is to look at structures and ask yourself, how hard is it for any one “unit” in your “system” to get stuff done. Everything that cuts across areas of responsibility adds complexity. The Team Topologies book suggests to favor teams that are end-to-end, that fully own a problem to be solved, supported by platform teams and teams that manage a very complex piece of technology.
For those teams that need to collaborate in a pipelining fashion, by all means look at the whole system to identify the bottlenecks and focus on improving them. This is the central idea behind the “Theory of Constraints” by Eliyahu Goldratt. You need to limit the work in progress so that it matches your bottleneck, everything else is just busywork.
Maybe there is even another approach, looking into ways for people to cooperate more effectively. I briefly mentioned pair programming above, and I have to admit I historically believed it cannot be done, or only by a small number of people who know each other very well and have figured out a way to bounce off ideas of one another.
Ironically, in my experience, just bouncing off ideas of one another is not the way this works well. What you can end up with is people throwing their ideas into the ring just for others to find faults in it. In the worst case, this can turn into a competition who knows most and who is smartest.
Unless you take care everyone has different understanding of the problem, and there is no focus on information gathering and constructive creativity. I’ve recently starting to read more about design thinking approaches, that use, for example, brainstorming both to collect information and generate new ideas. I found these things to be surprisingly effective at joint problem solving.
In any case, we definitely haven’t figured out how to write software at scale, but I also would rather not believe this is just how everyone does it.
Note: Changes to the Full-Text RSS free service
Just after Christmas I made a fun little Codepen demo recreating realistic-looking paper snowflakes in CSS, inspired by our homemade decorations!
Our latest benchmark of Mobile UX reveals that 52% of e-commerce sites still have severe mobile UX issues.
On April 21, we’ll be making some updates to Figma’s free Starter plan. Ahead of that rollout, we’re sharing what’s changing and what you can expect.
Summary In this tutorial you will learn: What Style Dictionary is How to structure things in Sketch or Figma for it to work its magic of translation via Stratos Tokens and out to iOS, Android and SCSS How to install
“Good news about display: contents and Chrome” — Rachel Andrew notes that the accessibility danger of using display: contents; is fixed in Chrome. The problem was that, say you had a parent div that is laid out as a grid and inside
Today we’re very proud to launch the brand new, totally reworked Stratos Tokens 2021 to the world. After more than one year in development we have taken all the findings from our pre-release versions, rebuilt it from scratch and are
In this ALL YOUR HTML coding session you’ll learn how to create the globe and add cities to it using Three.js.
This coding session was streamed live on April 4, 2021.
Check out the live demo.
The post How to Create a Globe and Add Cities using Three.js appeared first on Codrops.
April 5, 2021 First off, accessibility is tackled at the design stage. For my engineering or product friends in the audience, this statement is not meant to deter or depreciate any effort that takes place in other sects of product development. Rather,
At each company I’ve worked, we have had a split between time spent on Product initiatives and Engineering work. The percentages always changed, sometimes 70% Product, 30% Engineering, sometimes as much as a 50/50 split. The impetus is to make sure that Engineering spends a portion of their time building new features, but also ensures we can do “our own” work such as address technical debt, upgrade systems, and document our code.
The trouble is, it’s one thing to say this at the outset, and another to make it a reality. There are some reasons that I’ve seen this model fail, not because people don’t understand in theory that it’s valuable, but because in practice, there are some common pitfalls that you have to think through. We’ll cover some of these scenarios from the perspective of an Engineering leader so that we can address a good path forward.
Some of the pointers below are reactions and planning based on what can go wrong, so let’s talk first about the challenges you can encounter if this isn’t set up right.
Product may have conflicts, either with the work itself or the time involved. This can strain the relationship between Product and Engineering. If they are caught by surprise, you can potentially find the boundaries of your work getting more restrictive.Your engineers might not understand what’s expected of them. Parallelization of efforts can be hard to do, so building a good process can provide clarity.Maintenance path should be clear: Are you planning on making a giant system upgrade? This may affect other teams over time and if you’re not clear about eventual ownership, it could come back to haunt you. 👻
As nice as it is to have some freedom in your engineering time, communication, planning, and clear expectations can help make sure that you avoid any of the issues outlined above.
Photo by Akson on Unsplash
Once you figure out what problem you would like to tackle, it’s critical to write up a small one-sheeter that you can share with stakeholders on the nature of the work, the amount of time it’s going to take, and why it’s important.
If it’s a large project, you can also scope those pieces down into GitHub/GitLab/Jira issues, and add a label for the type of work that it is. This is great because you can use whatever project management system you already use to elevate the amount of work and expectations weekly. It’s good to keep the dialogue open with your Product partners on scope and the nature of the work so they aren’t surprised by other work getting done. This will largely vary by the culture of the team and organization.
This can help provide clarity for your Engineers, too. If they understand the nature of the work and what’s expected of them, it’s easier for them to tackle the small issues that make up a whole.
You may find that it makes less sense from a focus perspective to have every engineer split time across product and engineering projects. They may instead prefer to split the work up between themselves: three people on product work for a few weeks, one person on engineering work. There are also times where everyone does need to be involved so that they have equal institutional knowledge (migrations can be like this, depending on what it is). Your mileage may vary based on the size of the team, the amount of product work, and the type of project.
Communication helps here, too — if you’re not sure what the right path is, it can help to have a small brainstorm as a group on how you want to get this done. Just be sure you also align everyone with why the project is important as you do so.
Types of projects
There are many types of projects that you can create in your Engineering team time, and each has slightly different approaches from what I’ve seen, so let’s go over each one of them.
Let’s address technical debt first because that’s one of the most common pieces of work that can unlock your team. For every feature you write, if Engineering effort is slowed, you’re not only losing time in terms of product development, you’re also losing money in terms of engineering time in salary.
A bit of technical debt is natural, particularly at smaller companies where it makes more fiscal sense to move quickly, but there are some points where tech debt becomes crippling for development and releases, and makes a codebase unstable. Sometimes it needs to be done immediately to make sure all your engineers can work efficiently, and sometimes it’s gradual.
In a lot of cases, the technical debt pieces are things you learn you need by a bottoms-up approach: the devs that are closest to working with the system will know best what day-to-day technical debt exists than Engineering Managers (EMs) typically will. The challenge as an EM is to notice larger patterns, like when many folks complain of the same thing, rather than one dev who may have a strong opinion. Asking around before you start this type of project can help — poll people on how much time they think they’re wasting in a given week vs the prospect of an alternative.
Sometimes technical debt is a matter of a large amount of refactor. I’ve seen this go best when people are up front on what kind of pull requests (PR) are necessary. Do you need to update the CSS in a million spots? Or convert old class components to hooks? You probably don’t want one huge PR for all of it, but it doesn’t make sense to break this work per-component either. Work together as a team on how much each PR will hold and what is expected of the review so you don’t create a “review hole” while the work is being done.
Photo by heylagostechie on Unsplash
A lot of companies will do hack week/innovation week projects where devs can work on some feature related to the company’s product untethered. It’s a great time for exploration, and I’ve seen some powerful features added to well-known applications this way. It’s also incredibly energizing for the team to see an idea of their own come to fruition.
The trouble with doing these kinds of projects in the split engineering time is that you can, at times, make the Product team feel a little slighted. Why? Well, think of things from their perspective. Their job is to put forth these features, plan carefully with stakeholders, put together roadmaps (often based on company metrics and research), and get on the Engineering schedule, usually working with a project manager. If you spend half your time working on unplanned features, you can potentially fork an existing plan for a project, go against some of the known research they have, or simply slow down the process to get a core make-it-or-break it feature they need.
The way I’ve seen this play out well is when the EM communicates up front with Product. Consider this a partnership: if Product says that a particular feature doesn’t make sense, they likely have a good reason for thinking so. If you can both hear each other out, there is likely a path forward where you both agree.
It’s good to address their fears, too. Are they concerned that there won’t be enough time for product work? Ask your team directly how many weeks at half time they think it might take (with the expectations that things might shift once they dig in). Make it clear to everyone that you don’t expect it to be done at a break-neck pace.
Ultimately, communication is key. Ideally, these are small projects that won’t derail anything that can be done in parallel to the regular work. My suggestion is to try it with something very small first to see what bumps in the road there might be, and also build trust with Product that you’ll still get your work done and not “go rogue.”
The final piece of this is to figure out who is responsible for metrics, outcomes, and when things don’t go well. Part of the reason Product gets to decide direction is because they’re on the hook when it fails. Make sure you’re clear that as an Engineering leader, you’re taking responsibility for outcomes, both the good and the bad to maintain a good relationship.
Slow, ongoing work
This is probably the most clear-cut of any of the types of projects and will likely get the least amount of pushback from anyone. Examples of this type of work is internal documentation, tooling (if you don’t have a dedicated tools team), or small bits of maintenance.
The communication needed here is a little different from other projects, as it’s not necessarily going to be one constrained project that you ship, but rather an iterative process. Take documentation as an example: I would suggest building time for internal documentation into any feature process.
For instance, let’s say you created a new feature that allows teams to collaborate. Not everyone across the company may know that you created a microservice for this feature that any team can use, and what parameters are expected, or how to add functionality down the road. Internal docs can be the difference between the service being used, as well as your team being asked to pair with someone every time someone needs to use it. Or worse: them trying to hack around and figure it out on their own, creating a mess of something that could have been worked on quicker and more efficiently.
Unlike the innovation projects, slow, ongoing work is typically not something folks really crave doing, so setting a process and expectations up straightaway works best. Internal documentation is a sometimes hidden but very important part of a well-functioning team. It helps with onboarding, getting everyone on the same page about system architecture, and can even help devs really solidify what they built and think through how they’re solving it.
Photo by Christina @ wocintechchat.com on Unsplash
Migrations are handled a little differently than some other types of projects because it likely affects everyone. There is no one right way to do this, and will also largely depend on what type of migration it is — framework to framework, breaking down a monolith, and migrating to a different build process or server all may have different approaches. Due to the fact that each one of these is likely an article of its own, let’s go through some high level options that apply to the organization of them.
My first suggestion is to do as much research as possible up front on whatever type of migration you’re doing. There’s no way to know everything, but you don’t want to get part-way through a process to find out something critical. This is also helpful information to share with stakeholders.Are there internal debates about what direction your company should head in? Timebox a unit of time to work through the problem and make sure you have a clear decision-maker at the end. A lot of tech problems don’t have one “true” solution, so having one owner make the decision and everyone else disagree and commit can help. But you also want to give a moment for folks to have their voices heard about what gives them pause, even if they are in disagreement — they might be thinking of something you’re not.Document a migration plan, both at a high level and then work through the impact on each team. This is also a great time to explain to Product why this work is important: is your codebase becoming old and can no longer play well with other libraries and tools? Did a new build process come out that could save your engineers time in a release process? Help them understand why the work is critical.Be clear about maintenance and ownership. If one team migrates a build process that then causes issues for another, who’s fixing things to unblock that team? You should decide this before it happens.Some migration paths allow you do things slowly over time, or team by team, or do a lot of the work up front. However, there is usually a time when it’s going to be critical and all hands on deck are needed. Unlike some of the other work that can be parallelized, you may have to work something out with Product where all other feature work is stalled for a little bit while you get the new system in place. If you work closely with them, you may find that there are times in the season where you naturally have more of a customer lull, and it could give you the breathing room you need to get this done. I’d suggest that if they’re willing to let you take Engineering time to 100% for a little while, you return the favor; and once the platform is stable, dedicate 100% of the team’s time to Product work.
This final step might seem optional, but it’s a big deal in my opinion. Your team just pulled off something incredible: they parallelized efforts, they were good partners to Product, they got something done for the Engineering org at large. It’s crucial to celebrate the work like you would a launch.
The team needs to know you value this work because it’s often thankless, but very impactful. It can also build trust to know that if something hairy comes up in the future, that it does actually help their career path as well. Celebrating with your team what you accomplished costs very little, and has great cultural impacts.
The post Splitting Time Between Product and Engineering Efforts appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.