Perils of Documenting Architecture

Writing Big Architecture Document, I couldn't help thinking of a nice Russian saying. It is about translation; rephrased for architecture and translated (!), in English it becomes:

Architectural documentation is like a lady. When she is fair, she isn't pretty. When she is pretty, she isn't fair.

Is Agile Any Good for a Startup?

Agile is about reducing risk, improving predictability, and having more fun. Startup is about taking risk, making surprises, and having more fun. Is agile any good for a startup?

Startup can’t reduce risks, they take it.
Startup can’t improve predictability – there is none.
Startup can’t be any more fun – it is already too much to bear.

Despite rumors, agile is a disciplined process. It promise future benefits, but comes with a cost. Bad trade-off: start-up is a life boat that needs to get to shore before short supplies run out.

Optimizing dev process? Why bother improving speed in a future, get it going now! Code maintainability? Why bother, if it goes down the toilet faster then it’s written. Continuous integration, auto build, unit testing… Why bother? These best practices proved themselves in the industry. So what? A research lab is not like a production line.

The only thing from agile that suits really well is the motto: "Every day is a good day to die".

Ok, there is more. They share fundamentals. Focus on people, working software, customer collaboration and embracing change.

I am being controversial to stir the pot. Those who know me are not surprised. I don’t know if agile is any good for a start-up. Do you know? Leave a comment.

Effects of Defects: Grey Scope Creep

Is boosting productivity simple? Yes! Just cut out craploads of code! One problem here. The gap between code complete and feature done is bigger then it appears. That was my thought as I was looking at statistics.

On average, a developer cuts off 300 lines per day, some true heroes claim more. This “productivity” comes with the price of 100 defects per 1000 lines of code. Finding defect and fixing it is on average 4 to 16 hours [1] [2]

Do the math: Your kick ass star developer produces 500 lines a day. This creates up to 80 hours of extra work to himself, the dev team and their tester buddies. 10 damn days! I call it “grey scope creep”.

At first, this statistics seems totally off. But can’t you remember such a kick ass code monkey? you surely know a few. Now go over all these steps to fix a defect: cutting the build, installing it in QA, testing, finding the bug, writing a bug report, assigning it back to development, reviewing, trying in vein to reproduce… “Works on my machine”, sending it back to QA”, and finally, after a couple of round-trips, it’s fixed. Than regression sticks out an ugly head, and the high 16 man-hours per a bug looks too good to be true.

So, is boosting productivity simple? Yes! Less bugs in, more bugs out! One problem here. But enough on problems, let’s get positive and move on to how fight grey scope creep.

First, if the kick ass developers only care about the joy of cutting code, not shipping the software, they got the boots. Don’t regret, they produce more work then they get done. It is not about developers developing and testers testing. It is developers and testers working cooperatively to ship a software. We got space for local optimization.

Second, good software practices are to the rescue. Pair programming, design and code reviews, test driven development, etc… They surely slow down the LOC/day pseudo-performance (less bugs in) and reduce the number of defects. Pair programming by itself brings 15% less bugs, with healthy 15% slow-down of LOC performance [3].

Third, redefine “done”. Fresh features are marked done, and disappears somewhere in QA to eventually fire back at unknown time with unknown bugs. Grey scope creep. Stop it. Instead, insist on taking less but making it “done” within an iteration. Done reads fully developed, thoroughly tested, debugged, fixed including regression, and accepted by product owner. If this bring development to a deadlock, it’s one of the two. You may be blessed to fail faster and cheaper. After all, if you can’t get “done” just one feature, how would you ever be done with the entire project? Or the team overcomes the crisis and changes the working habits. The shortened feedback loop and fixing bugs as you make it leads to less time per bug fix. The grey scope doesn’t creep beyond the iteration. Problems become obvious early enough to to deal with them.

Finally, until you fix the grey scope creep, your estimations could be off, up to 10 times! Measure well.

So, is boosting productivity simple? Yes! One problem here. Trying to address it may expose the stakeholders to too much truth about the state of the project. Figure out how to deal with this truth. Or wait to my next blog, I have some thoughts about it.