Comment by xvaier | Hacker News Reader

Comment by xvaier | Hacker News Reader

As a lead developer building a platform dealing with the intricacies of union agreements and labor restrictions, this summarizes exactly the thought process that my team has gone through in the last year.

We started with a simple problem that plagues HR departments in every conceivable industry with unions, finding substitute personnel and erroneously assumed that it was a simple fix. Over the past year and a half we have accumulated a great deal of knowledge after interacting with as many people as possible and have finally released a version that meets our original criteria (and much more). It was obviously not a simple fix.

If I have one thing to tell anyone who is looking for business ideas to try out their new programming skills on, I strongly suggest taking the time to learn as much as possible about the people to whom you want to provide a solution, then recruiting one of them to help you build it, lest you become another project that solves a non-issue beautifully.

Yes. The most successful projects I have worked on, we (the dev team, not project managers, not designers, etc) went on-site often. We observed our customers. We had lunch with them. We stood behind them as they worked. We asked them questions. We were on very friendly terms with them.

We built systems that literally had people say, "Oh, thank God!" when demoed. I haven't seen any other development methodology that matches it. You really have to understand a problem at a deep level in order to reason well about it.

I'd love if that methodology were more common. The "traditional" method usually involves companies insisting we provide waterfall style proposals and they don't want to invest in up-front "mini-project" of having people analyze the problem _first_.

And heaven-forbid any developer actually calls up a customer or subject-matter expert without routing absolutely everything through one or more layers of middlemen and bureaucracy.

"Just send me your questions and I'll pass them along..." Because no one has _ever_ had a question answered and had a follow-up question based on the answer before... /s

True story: Myself and a bunch of internal customers are literally less than 50 meters away in the same office. The blessed middleman is in a different timezone 8 hours ahead.

So instead of a quick conversation 30 minutes with helpful whiteboard doodles, I have to compose my questions and decision-tree into an e-mail and wait at least for a day or two for a reply that may or may not be useful.

Are there repercussions to just walking over and asking them then forwarding the middleman a summary / recap?

There was a "Hey, don't do that, X needs to be in the loop" complaint. (Didn't see it myself, but technical program manager who was also in on the meetings told me.)

Later that remote person left the company, and the position was left unfilled for a year and some projects got mothballed.

I came in my company as a team lead to a very disfunctional department, the developers were frustrated because of unclear requirements and the business side was upset because they could never get their deliverables despite "very clear" 100 page documentation specs and a "detailed" list of requirements.

They would email each other even though they were in the same office more to document everything and CYA than for communications.

On the dev side, I banned internal email for discussions. I told them that they must talk to people first if they are in the office and then send emails of documents, screen shots or whatever.

I also took it on as personal mission to never say "no" to any request and always talk to the person who was making the request - in person - see if we could come up with an acceptable compromise and tell them how it would affect their deliverable.

The book Talking to Humans, shows this concept well, plus the book is free.

http://www.talkingtohumans.com/index

Thank you for the suggestion, it was an excellent fast read, quite concise and insightful.

Absolutely! Being able to watch our customers use our application in production environments, observing how they used it and how they perceived certain features has been so enriching.

We would have spent at least 10 times longer trying to get these insights otherwise, if there was even a possibility that we would arrive to the same conclusion.

It takes a little time to get over the fact that you are no longer building this product for yourself (unless you are building dev tools), but seeing customers use your product happily and telling you how much they value it is well worth the investment.

Reply on news.ycombinator.com