My response to Agile Manifesto, the M.f.S.C. and the like.
This is called “Enlightened Development: 9 not so obvious software development principles learned the hard way”.
We play by our own rules.
From experience we know: in any game, playing by the rules is more fun. Inspired by Kanban and Scrum we come up with our own game rules. The rules give predictability and protect us from our human emotions like panic or greed. Instead of breaking the rules or ignoring them, we adjust our rules, as often as necessary.
We solve fundamental problems first.
From experience we know: a house built on a shaky foundation can be finished faster, but who would want to live in it? We use business requirements as the initial impulse to discover the fundamental problem. Having solved the fundamental allows us to propose solutions to whole classes of problems the business didn’t even think about.
We communicate everything to everybody.
From experience we know: software project can only move as fast as the information exchanged between its team members. We’re religious about keeping every team member in the loop before decisions are finalized, so they can give their advice, adjust their plans, or veto the whole thing. We identify and eliminate communication barriers: time, space, language, culture. We choose names for things and stick with them. We cut through the bullshit.
We solve one problem at a time.
From experience we know: multitasking is good for tasks that require no thinking, software engineering is not one of them. This is why, instead of assigning multiple tasks to every person, we gang up against one problem at a time. This minimizes communication waste, improves quality, reduces rework, and saves everybody’s time. We kill one bird with one stone, again and again and again.
We give developers respect they deserve.
From experience we know: treating “the business” as a customer whose every wish is a command for development is a bad way to evolve sustainable architecture. Software being the face of the sales and the heart of the operations, we expect professionals to collaborate to find the best solution to each problem. PMs and BAs exist to take non-technical burden off developers, so they can focus on solving the essential problems.
We seek feedback and act on it.
From experience we know: there is always room for improvement. We’re harsh to ourselves and encourage others to be outspoken about our shortcomings. We use group accountability and shared vision as a way to protect individuals from stress associated with continuous improvement. The feedback is not merely a vent for frustration. Knowing that every complaint has an actual cause behind it we actually act on every single one.
We don’t commit to dates.
From experience we know: in software development the deadlines are lies. We don’t lie to ourselves or our customers, that’s why we don’t commit to dates. We don’t need a stick of deadline to keep us stimulated; instead we work our best every hour of every day, arriving at the best product in the shortest time possible.
We simplify.
From experience we know: simplicity is an exhaustible resource, and over-complication is not sustainable. The best solutions are built from small number of simple pieces that can be combined together in an infinite number of ways. We strive to keep our software and our UIs simple. We’re happy if we can cut out 80% of extra complexity by only solving 80% of the problem. We don’t confuse “easy” with “simple”, and we take time to solve problem in a simple way so we can keep moving fast in the future.
We master the economics of time.
From experience we know: in software development, money are cheap, time is expensive. Invested time today, got more free time tomorrow — that’s a profit. Ended up with more maintenance taking up a portion of your future time — you’re at loss. This simple economics of time is what drives our software architecture and task prioritization. This is why we automate the hell out of every manual operation to be performed by a developer and don’t allow any overhead to creep in.
