Monthly Archives: July 2014

Quora Answer: What is the best way to convince a founder that agile is not the best way to do everything for an effective startup?

I originally wrote this as an answer to a question on Quora.

Good luck with that. At this point “agile” should be considered a psychological disorder in need of treatment for people who cling to it with a death grip no matter how badly it fails in their organization. Let’s hope your founder is not one of those.

Find out why they think it’s so great. It’s probably because they’ve heard that it makes developers more effective and causes you to ship higher-quality software more often. In many cases and in many organizations this is true, and they’ve probably worked somewhere where that was the case. I’ve seen it work better for larger organizations than small ones.

In places where it doesn’t work, it just adds busy work and friction to an already-challenging process. Often trotted out is the No True Scotsman fallacy — that says that if agile is failing for you, you’re not doing agile right. No, in some places it’s just doesn’t work. If you’re a smart person that it doesn’t work for, it doesn’t mean that you’re broken. You just work differently and it takes a different approach to be effective.

In many startups, adhering to some arbitrary set of rules will make people less productive than just caring about the quality of the product, doing the best you can, and making sure you’re doing the right things. Yes, you need source control and an issue tracking system and have to have your design goals written down somewhere and understood by everyone involved. It’s not because you need to keep track of whether someone is working — that’s always obvious — but you need to have enough structure to know what you’re doing now, and doing next.

Some people use agile as a crutch and excuse to not actively manage their teams. It is NOT POSSIBLE to put your development team on some sort of auto-pilot method treadmill and expect an awesome product. The builders need to talk to the business people ALL THE TIME. If this really is a proper startup, every single day you know more about how to build what you’re building and what things are or are not possible or easy/difficult, and you’ll have to revise your development plan constantly. If you’ve gone more than a week without any priorities changing, it may be possible that your company has exactly the right laser focus on exactly the right thing. More likely is that the business is not learning enough about its customer’s needs fast enough. And, in some places two or three week sprints are just too slow and cumbersome.

It might also be possible that you’ve not given it enough of a chance, but I bet you wouldn’t be asking this question if you hadn’t already given it an earnest try.

Quora Answer: Is it rude to change a co-worker’s badly written code?

I originally wrote this as an answer to a question on Quora.

Full question:

“I joined a company as a new grad and currently working with two mid level and one senior designer. It’s a chip design company. One of my co-worker’s code is very badly written and I am pretty sure there are many other good ways to implement the same thing. Badly written code bugs me a lot and I’m tempted to change/improve it. Will it look bad if I go ahead and change his code? Or should I ask his permission beforehand ? I’m not sure what will be a good move as I’m comparatively new in industry. I don’t wanna look arrogant!”

Yes. It’s also rude to write bad code.

The best way to handle that is a code review. It’s not necessary to have anything formal – just spend a few minutes going over the code together so you can point out what had issues and why.

Just changing the code without communication will cause two problems: The original writer is likely to resent it, and the original writer won’t learn anything and will keep doing things the same way. There’s also a risk that you don’t fully understand the intent or scope of the changes and your “fixes” might break something.

Don’t make it adversarial or approach it in a way that puts the other developer on the defensive. That will make them non-receptive to the conversation, and the goal is to improve the code and the developer both now and in the future.