Component-based Development vs Cotton Picking
Thoughts on how React can demystify the mythical man month and make frontend development easier with a distributed network of engineers, just like cotton picking.
The Mythical Man-Month
The Mythical Man-Month is an essay by Fred Brooks. In this essay Fred writes about the difficulty in scheduling software development project and their time estimation. Specifically stating that a project takes X amount of Man-Month, so the more engineers are assigned to it, the faster it will get done. For example estimating that a project will take 9 months, then assigning a team of 9 engineers will result in the project delivered within 1 month. Of course in reality this could not be further from the truth.
“..the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.”
Let’s dive into this part: “a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton”
The writer uses cotton-picking as an example for a task that can be distributed to many workers that doesn’t need to know about each other’s work.
Atomic Design
In 2013 Brad Frost published a blog post where he coined the term “Atomic Design”. In the post, Brad describes a way of designing systems by breaking the into smaller and smaller pieces, called Atoms, Molecules, Organism, Templates and Pages. These pieces are essentially components.
We’re not designing pages, we’re designing systems of components. — Stephen Hay
This approach makes building user interfaces much simpler by writing component-based user interface code.
The Rise of Components-based Frontend Development
Around the same time as Atomic Design was published (2013), a framework for building user interfaces based on components was open-sourced by Facebook. Its name: React.
Today React is leading in popularity amongst many other Javascript frontend frameworks like Angular and Vue.js. One thing in common to all the top frameworks is that they all promote component-based development.
To make things better, web components are being drafted as we speak to become a native part of browsers, which means component-based development will become available even without using any third-party Javascript framework. Web Components Official Draft — Link
Web Components are a set of features currently being added by the W3C to the HTML and DOM specifications that allow for the creation of reusable widgets or components in web documents and web applications.
Distributed network of developers coding in parallel
Component-based Development and Cotton Picking
A user interface can be broken to many small components. If you are a developer that is handed-off a design for a web app, the first thing you probably do in order to build the whole app is to break it into the smallest components possible and coding them up. If best practices are followed, these components are independent of the app you are building. They are reusable, encapsulated, and testable.
The UI components can be developed independently from each other. That means that they can be developed by different developers. The developers don’t even need to communicate with one another. Each developer creates a fully functionally, re-usable, testable by itself component, that receives input and provides output, regardless of where it’s being used, and knows nothing about the app it’s being used in.
The task can be partitioned among many workers with no communication among them. Just like picking cotton in The Mythical Man-Month.
The concepts being discussed in this article are being actively developed by us at Anima. If you’re interested in streamlining your frontend development or in getting paid for developing components on your free time click here.