top | item 14770402

(no title)

xvaier | 8 years ago

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.

discuss

order

christophilus|8 years ago

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.

mfoy_|8 years ago

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_.

xvaier|8 years ago

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.