I W asted Three Days Because the Brief Was Never Clear

Three days after delivery , the client said, " I thought it was going to be the other version." I stared at my screen, not sure whether to blame myself or them . Then I came across a line on a developer forum that hit me square in the chest : "Requirements are never complete at the start of a project ." It's not that the client was being difficult — that 's just how projects work. I'd always assumed it was my communication skills letting me down. Turns out it 's a trap everyone falls into.

What These Laws Are — and Who's Using Them

There 's a site called Laws of Software Engineering that collects decades of hard -won lessons from the programming world . Sounds technical, but when I actually read through it, almost none of it is really about code. It's about people, requirements , time, and complexity.

Take Brooks ' Law: adding people to a late project makes it later. My friend Xi aowen ( brand designer in Shanghai) landed a big contract last year and brought in two friends mid -project to help. The time they spent syn cing and al igning ended up co sting more than the help saved — they shipped two weeks late. She told me afterward , "I should 've just pushed through it alone ." That 's exactly what this law describes .

Another one I keep coming back to: " Any system that is still in use will continue to grow more complex." Your rate card, your client roster , your content pipeline — if it 's still running, it's getting messier. That 's not a personal failure . It 's a pattern .

How to Actually Use This ( No Tech Background Required )

Cost : $0 — the site is free.
Time: About 15 minutes to read the core 10 laws.
Technical barrier : None — browser auto -translate works fine the whole way through .
First step: Open law so fsoftwareengineering.com , scroll down, and read " Brooks' Law" and the "Complexity" entry first .

My own approach: before starting any new project, I run through these laws and ask myself, "which of these p its am I most likely to fall into this time ?" Then I bring it up in the first client conversation — not as a lecture, just so I know where the edges are.

This isn 't something everyone needs. If your project flow is already smooth , feel free to skip it entirely .

Advice by Stage

If you're just starting out and still figuring out how to take on clients : I'd suggest reading just two laws — "requirements will change " and "complexity compounds " — then thinking back to your last project and spot ting where the rework happened. More useful than any methodology guide .

If you already have one or two steady clients: Print out Brooks ' Law and stick it next to your monitor . Next time a client says "should we bring someone else in to help you ?" — you'll already know your answer.

If you're scaling up and starting to delegate or outsource: The section on communication costs growing expon entially with head count is worth reading carefully . It'll help you think clearly about when to add people versus when to cut scope .