I’m on a project now that requires touching all of the UIs in a minor way, and this is going to be fairly difficult to do since At Stitch Fix we have AngularJS, Angular 4, React, jQuery, and an internal JS framework. Now, one person can rotate the keys in under an hour (most of which is spacing out application restarts).Īnother example: JavaScript frameworks. The next time it happened, we spent three days of six developers’ time to make everything consistent (yup), so it could be automated. We spent 20+ engineer-hours manually rotating the keys. When it came time to rotate those keys due to an employee departure, we couldn’t automate it. Microservice API keys were placed in the UNIX environment. We failed to establish a consistent naming convention for where internal The team so that developers could spend most of their time solving business problems, not technical problems.Įven minor inconsistencies can have grave cost. They would want undifferentiated problems to have a single solution across No technical leader would want this for their team. Developers that must work across systems (which becomes highly likely as a team grows) must learn all the different ways to do something to be able to work. Now have to decide which way to do something, or if there should be an additional way. When there are many ways to do the same thing, developers A team that continually re-solves problems or has to maintain many different methods of solving the same technological issue will be slower to deliver value.Ī lack of consistency has long-term negative effects on a team's productivityĪ lack of consistency has long-term negative effects on a team’s productivity. Grow the team and extends the time during which a single person can understand the entire technical architecture.Ī team that embraces this will basic practice be able to move quickly and maintain a focus on the specific business problems they solve. This work should become a convention on the team unless there’s a strong reason to the contrary (and personalįurther, if same things are the same (such as internal application architecture, naming, project structure), it becomes easy to Instead, that developer should copy or re-use the work done by theįirst developer. Is little value in another developer re-doing this work. If a developer has spent time digging into a technical problem, coming up with a solution, and getting it into production, there #CULTURE OF INDIRECTION COMMUNICATION DRIVER#When growing a team, it’s important to use consistency as a driver for conventions and technical decisions. #CULTURE OF INDIRECTION COMMUNICATION CODE#What code changes were required were almost entirely scriptable because of the overall consistency in the design and structure of our applications. This has allowed us to make a few drastic changes over the years without incident, and made onboarding developers far more straightforward than if each team was doing its own thing.įor example, when we moved from Heroku to AWS, we were able to do so without major downtime or production incidents, and without major code changes. “Arbitrary Inconsistency Should Be Avoided” was one of our written-down architectural principles.Įven now, many things in the Stitch Fix engineering team are consistent, regardless of who did them or why. Time, the good decisions were almost always about being consistent, and the bad ones where the introduction of arbitraryĮarly on, the entire team (of six developers) met regularly and agreed that consistency was a value we held and that we would foster as the team grew. Long-reaching effects on what is now a large engineering team of over 100 developers at a public, profitable company. While I was not the first technical hire at Stitch Fix, I was early enough to make a lot of technical decisions that have had
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |