Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Hard Thing About Software Development

linkedin.com

Post reply on HN
Print view View original

31–40 of 105 posts

Re: The Hard Thing About Software Development

#31

Post by phkahler »

Favorite line "... the software development process is exploratory by nature."

I always say the customer/client does not have requirements, they have problems. You will not discover all the requirements until you start solving some of the problems and providing solutions. Only then will they say "oh but...." and drop more requirements on you that they didn't think of up front.

Back to that quote. It's not that software development is exploratory in itself. It's that the development is intertwined with an exploration of the problem being solved.

Re: The Hard Thing About Software Development

#33

Post by Terr_ »

mfoy_ wrote: post #28
christophilus wrote: post #26

Earlier quoted context omitted.

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 m…

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.

Re: The Hard Thing About Software Development

#34

Post by mason55 »

phkahler wrote: post #31

Favorite line "... the software development process is exploratory by nature." I always say the customer/client does not have requirements, they have problems. You will not discover all the requirements until you start solving some of the problems and providing solutions. Only then will they say "oh but...." and drop more requirements on you that they didn't think of up front. Back to that quote. It's not that softwa…

> and drop more requirements on you that they didn't think of up front

I think one of the important qualities of an architect is to anticipate what these requirements are going to be and define solutions to them ahead of time.

I have this conversation all the time with our client-facing team.

Me: "What is supposed to happen if this data changes?"

Colleague: "Well the customer didn't give us a requirement for that so we don't have to worry about it"

Me: Screams inside

Re: The Hard Thing About Software Development

#35

Post by oldrny »

haburka wrote: post #2

I agree completely. Rarely the hard problems in coding are thinking of a clever algorithm, or solving a particularly nasty scaling problem. Usually I've struggled the most with understanding and building what the customer needs. A spec can be interpreted many different ways and will always have to be polished after its completed. Someone who doesn't know what the customer expects will almost certainly create an imple…

It seems like your suggestion is a little backwards -- computer science is its own thing, and for some reason, people started thinking that computer scientists are ideal software developers. Since that clearly isn't the case, employers should look for some other certification that's more in line with what they require from an employee.

Re: The Hard Thing About Software Development

#36

Post by sidlls »

haburka wrote: post #2

I agree completely. Rarely the hard problems in coding are thinking of a clever algorithm, or solving a particularly nasty scaling problem. Usually I've struggled the most with understanding and building what the customer needs. A spec can be interpreted many different ways and will always have to be polished after its completed. Someone who doesn't know what the customer expects will almost certainly create an imple…

> It makes me think that we're training the wrong people in college by making CS a very difficult, math heavy field which often causes the more human skilled people to drop out.

I disagree. I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. It's like suggesting a BS in Physics qualifies somebody to work as an engineer building a satellite. It doesn't, but that doesn't mean "physics is too math heavy." In fact, engineering a satellite requires almost as much basic mathematics education as a BS in physics requires (some exceptions might include the specialized mathematics required for upper-level theoretical physics concepts that may not apply at an engineering firm).

Re: The Hard Thing About Software Development

#39

Post by cercatrova »

christophilus wrote: post #26
xvaier wrote: post #6

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…

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 m…

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

http://www.talkingtohumans.com/index

Re: The Hard Thing About Software Development

#40

Post by xvaier »

christophilus wrote: post #26
xvaier wrote: post #6

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…

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 m…

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.

Post reply on HN