The best tool isn't always the most popular
While big web apps like YouTube and Facebook existed, they were built by large companies. No one expected regular developers to create projects of that scale alone or even in small teams.
The idea that development is getting too complex comes from buying into the belief that we all have the same needs and resources as giant enterprises.
But in the real world, software takes time and there are so many control structures around the process of making the outcome wholesome and valuable. These include: methods, version control, tasks, estimates, designs, concrete experimentation, meetings, deadlines and man-hours.
Remember, a framework is meant to make your life easier and save you time. However, if your project is small, the time spent setting up the framework might take longer than the benefits it offers. Frameworks are great for larger web apps, making them more interactive. But for smaller projects, they can complicate things and lead to inefficient workflows.
Thanks to recent improvements, you can do a lot with just HTML and CSS, but it often seems like they aren't good enough for today's web needs.
Choosing technology for your stack is an exercise of picking your own poison. Either choose a paid service and be subject to vendor lock-in in the future, or choose an open-source one and pray that the community continues to maintain it.
Many people think that the main reason software projects feel dull is that developers spend a lot of time going through complicated processes to build features. However, I've noticed that even exciting projects can become boring. The real issue is how people experience working on these projects.
When we discuss system design today, we often neglect an important aspect: people.
We live in this tension between the ease of new platform features and the complexity of our stacks.
System design shouldn’t just focus on technical details like flowcharts. We spend time planning the software but forget to consider the people who build it. We try to fix problems with our tools but rarely think about the biases and limitations of the people involved.
There’s a lot of talk about processes—like sprint planning and team culture—and about the product itself—like requirements and customer needs. However, this doesn’t always lead to better software. Decisions often ignore the people making them, leading to poor outcomes.
“The divide is between people who self-identify as a (or have the job title of) front-end developer yet have divergent skill sets. On one side, an army of developers whose interests, responsibilities, and skillsets are heavily revolved around JavaScript. On the other, an army of developers whose interests, responsibilities, and skillsets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, and so on.”
— Chris Coyier
Prioritizing tasks is good, but it should help bring order to chaos. Simply estimating tasks isn’t enough; we also need to understand the risks involved. For software projects to succeed, we must consider not only processes and products but also the people involved. A balanced approach with all three—Processes, Products, and People—leads to better results.
Many problems have simple solutions at their core. But people are complex and you need people to solve problems. Whenever you are faced with a problem, spend more time thinking through the people management side.
The Complexity of Decisions
According to Sheena Iyengar, a business professor at Columbia University, decision making involves three distinct mental tasks:
Knowing What You Want: Gain clarity on your goals and priorities to direct your focus and evaluate options effectively.
Understanding What Options Are Available: Gather information about the range of choices, enabling informed decisions that align with your goals.
Making Tradeoffs Between the Available Options: Recognize that every choice involves compromise by weighing pros and cons to assess potential outcomes.
5 decision-making tools for better organizational decision making
SWOT Analysis
Example: A software development company evaluates its services and products by identifying strengths such as a skilled development team and proprietary technology. Weaknesses might include high employee turnover. Opportunities could involve expanding into cloud services, while threats might include increasing competition from emerging startups. This analysis helps the company strategize its offerings and market positioning.
Decision Matrix
Example: When selecting a new project management tool, a development team creates a decision matrix to evaluate options based on criteria like cost, features, user experience, and integration capabilities. Each option is scored based on these criteria, allowing the team to compare projects quantitatively and showcase clear reasoning for their final decision.
Multivoting
Example: In a team meeting, developers brainstorm features for an upcoming software release. They list all suggestions, then use multivoting to narrow down the features by having each team member vote for their top three choices. This collaborative process helps focus the team on the most critical features based on collective input.
Pareto Analysis
Example: A software application is experiencing bugs. The development team collects data and discovers that 80% of reported issues stem from 20% of the code. By applying Pareto analysis, they decide to prioritize fixing those critical bugs first, leading to substantial improvement in application stability with minimal initial effort.
Multi-criteria decision analysis (MCDA)
Example: A company needs to choose between different technology stacks for a new application. Using MCDA, the team evaluates options—such as Node.js, Ruby on Rails, and Java—against various criteria like performance, scalability, community support, and development time. Each option is scored, allowing the team to make an informed decision that balances various needs and risks effectively.
It's really hard not to over-engineer web apps today because everyone wants to use what’s popular and worries about missing out. However, we should focus on our project goals and avoid letting our projects grow bigger than necessary. This applies to the tools we choose too; our decisions should be based on real needs, not just what others are using.