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

“This project will only take 2 hours”

web.eecs.utk.edu

Post reply on HN
Print view View original

191–200 of 279 posts

Re: “This project will only take 2 hours”

#191

Post by ajsnigrutin »

ivyirwin wrote: post #187
ajsnigrutin wrote: post #72

I've gone down this rabbitole before, and yes, there are things that take two hours, and there are things that take a lot more. The problem is the scope - ie. are you trying to do what you said you'll do (miniature software to log urls), or are you adding 100s of requirements to the scope (gui, filters, privacy,...). We had a bunch of .xml files containing some data, and someone wanted a .csv file... sure, an hour ma…

Yes, scope creep can significantly change the time requirements or even the entire, shall we say "scope". But I think it's just as important for us as developers to be aware of that on the initial request, in order to suss out the actual requirements. What does the process look like when we ask back, "are you going to need to have a total and rolling sum? should we think about making a gui so other people can use it…

My exact case was some reporting for some project (15 people, 36 months, 1 xml per person per month), to throw into excell and draw one graph, for one PPT, a one time deal, for one project manager to show the numbers on the report.

The end project, if I didn't stop the idea, would be a black box, where you would put any number of random xmls, and get exactly what the accountant wanted with one button... so an impossible task.

Re: “This project will only take 2 hours”

#192

Post by ajsnigrutin »

jrochkind1 wrote: post #177
ajsnigrutin wrote: post #72

I've gone down this rabbitole before, and yes, there are things that take two hours, and there are things that take a lot more. The problem is the scope - ie. are you trying to do what you said you'll do (miniature software to log urls), or are you adding 100s of requirements to the scope (gui, filters, privacy,...). We had a bunch of .xml files containing some data, and someone wanted a .csv file... sure, an hour ma…

You seem to be complaining that users/stakeholders have actual needs that may not be captured by their initial naive statement of the problem/solution/requirements. Indeed, they almost always do. Most users/stakeholders aren't good at technical specification of a solution that will meet their problem. It's part of our job to elucidate that in interaction with them. And then, even when you are good at technical specif…

To copy from my other comment:

My exact case was some reporting for some project (15 people, 36 months, 1 xml per person per month), to throw into excell and draw one graph, for one PPT, a one time deal, for one project manager to show the numbers on the report.

The end project, if I didn't stop the idea, would be a black box, where you would put any number of random xmls, and get exactly what the accountant wanted with one button... so an impossible task.

Re: “This project will only take 2 hours”

#193

Post by growse »

ivyirwin wrote: post #187
ajsnigrutin wrote: post #72

I've gone down this rabbitole before, and yes, there are things that take two hours, and there are things that take a lot more. The problem is the scope - ie. are you trying to do what you said you'll do (miniature software to log urls), or are you adding 100s of requirements to the scope (gui, filters, privacy,...). We had a bunch of .xml files containing some data, and someone wanted a .csv file... sure, an hour ma…

Yes, scope creep can significantly change the time requirements or even the entire, shall we say "scope". But I think it's just as important for us as developers to be aware of that on the initial request, in order to suss out the actual requirements. What does the process look like when we ask back, "are you going to need to have a total and rolling sum? should we think about making a gui so other people can use it…

Indeed. Much of the time, "scope creep" is actually just discovering what the requirements actually are. It's not that the requirements change, the requirement likely existed all along - it's just that no-body realised it. Iterating through feedback loops where you build something that meets the original ask, only to refine/change/add/remove things as everybody discovers that what they wanted is not in fact what they wanted is not an unreasable approach.

> I think I've been successful in my career because I've been able to listen to a client's request and then help them figure out what they are actually asking for instead of taking it at face value. That can be easier said than done on an internal team, but it changes the quality of the product and dynamic of the team significantly.

Sometimes you can explore the actual scope by skillfully working with the client before you build anything. Sometimes, however, you can only learn what the actual requirement is by building the wrong thing first.

Re: “This project will only take 2 hours”

#194

Post by BlargMcLarg »

shireboy wrote: post #145

I’d point out this isn’t a problem with estimation per se but with requirement gathering. The students didn’t press him for more specific requirements before offering an estimate. The real challenge though comes when the customer doesn’t know their requirements. They legitimately think they “just want a simple app to record urls”, but actually want all the other things listed. The thing that sets good developers apar…

Good developers, yes. Which takes experience, given the myriad of colorful personalities, politics and more. Though I don't think it is fair the responsibility is largely put on the developer for "underestimating" when often the corporate is big enough to have specific people gather these requirements and map them out as part of their day-to-day.

That's my main problem with this advice and the article. Of course anyone wants a developer who can do both development and figure people out to bring out the most perfect estimates possible. But it's getting to a point developers are starting to be the solely responsible people on top of ever increasing technical requirements, while being given the minimum amount of practice figuring all this stuff out.

Re: “This project will only take 2 hours”

#195

Post by JasonFruit »

AstralStorm wrote: post #105
TheOtherHobbes wrote: post #98

Earlier quoted context omitted.

One of my CS teachers actually said "The programming is always the easy part. Designing the features and the interface usually takes 95% of the time."

Your CS teacher never looked at a web browser from the inside, or at other actual big scale software.

Or maybe they were exaggerating for emphasis, as humans do.

Re: “This project will only take 2 hours”

#196

Post by WastingMyTime89 »

shireboy wrote: post #145

I’d point out this isn’t a problem with estimation per se but with requirement gathering. The students didn’t press him for more specific requirements before offering an estimate. The real challenge though comes when the customer doesn’t know their requirements. They legitimately think they “just want a simple app to record urls”, but actually want all the other things listed. The thing that sets good developers apar…

You deliver with the minimum you can get away with then improve from actual feedbacks, requests and data gathered from usage.

What people think they will want differs from what people will actually want which is not necessarily what data shows you should build. Build fast, improve incrementally.

The path highlighted in the article is exactly how you should not build a product. Don’t focus on all the things you could add, streamline your ideas as much as you can.

Re: “This project will only take 2 hours”

#197

Post by cline6 »

fumblebee wrote: post #82
jstx1 wrote: post #66

Reminds me of how some companies give take-home assignments to job candidates. > Here's a task that takes a day to do sloppily and at least two days for you to show your best work. We want to be respectful of your time so please don't spend more than 2 hours on it.

The take-home assignment seems to me a slightly broken system; it's easily gameable because there's zero supervision. Let's say there's two candidates for a position who are both asked to complete the take-home assignment, Candidate A and Candidate B. Candidate A is the superior candidate and spends only two hours on the task (as requested), and Candidate B spends 2 days. Candidate B submits the better assignment and…

From a hiring standpoint, the problem imo, is that employers set the timebox thinking that it means something when comparing candidates' solutions. I couldn't care less whether somebody spends two hours or two days on it. I want to see the best solution somebody can produce. I have engineers that can do things quickly and others that can do them more slowly, and both are infinitely more valuable to me than someone who can't provide a quality solution under any circumstance. In my experience, if you're filtering out the slower engineers that produce quality work you're going to be in for a very long hiring process and miss out on a ton of great engineers.

Re: “This project will only take 2 hours”

#198

Post by Hackbraten »

OneTimePetes wrote: post #154
ajsnigrutin wrote: post #72

I've gone down this rabbitole before, and yes, there are things that take two hours, and there are things that take a lot more. The problem is the scope - ie. are you trying to do what you said you'll do (miniature software to log urls), or are you adding 100s of requirements to the scope (gui, filters, privacy,...). We had a bunch of .xml files containing some data, and someone wanted a .csv file... sure, an hour ma…

In a ideal world- adding a simple user-gui, would be simple. As in- all edge cases and special cases, will not be handled, but just result in a error - that comes along with a suggested fix googled on stackoverflow. The "simple" program, teaches the users to program. Teaches them to leave an-alphabetism behind.

I don’t agree. Users can be in a hurry because they have to catch the train. They can have only one hand free because they’re holding a baby. They can be mentally handicapped so they’re cognitively unable to google stuff. They can be depressed and find themselves unable to accomplish even small tasks. Or they’re blind and there’s no accessible website that explains the error.

I think all those people have the right to use your app.

There’s a point in drawing a line somewhere. But please, don’t make your app hard to use /on purpose/, not even with good intentions in mind.

Re: “This project will only take 2 hours”

#199

Post by thewakalix »

chmod775 wrote: post #183

You can do feature creep for a long time. If you just want a basic working version (that will probably drain your battery), that can be done really quickly. This took me ~10 minutes: #!/bin/sh set -e while true; do URLS="$(xsel | grep -Eo "(http|https)://[a-zA-Z0-9./?=_%:-]*")" && if [[ ! "${URLS}" = "${OLD_URLS}" ]]; then echo "${URLS}" >> urls.txt OLD_URLS="${URLS}" fi sleep 1 done;

Using clipnotify[0], one could fix the busy-wait issue pretty easily.

[0] https://github.com/cdown/clipnotify

Re: “This project will only take 2 hours”

#200

Post by JoeAltmaier »

jiggawatts wrote: post #78
ajsnigrutin wrote: post #72

I've gone down this rabbitole before, and yes, there are things that take two hours, and there are things that take a lot more. The problem is the scope - ie. are you trying to do what you said you'll do (miniature software to log urls), or are you adding 100s of requirements to the scope (gui, filters, privacy,...). We had a bunch of .xml files containing some data, and someone wanted a .csv file... sure, an hour ma…

I vaguely remember a rant some famous Linux developer went on about how setting up printing in Linux requires a dozen parameters, half of which are arcane nonsense that the printer manufacturer themselves probably doesn't know how to set up correctly. Meanwhile, on an Apple or Windows computer it can be literally just plug and print. The difference is that hiding those arcane input parameters takes work , and a lot o…

Ha! Printers!!

I worked on an OS called CTOS back in the day. It was difficult to set up printing, because there was no feedback. It worked or it didn't, and there were queues to configure and services to install and network connections...

Somebody in a trade rag wrote "Its easy to print on an Apple, difficult on an IBM PC and impossible on CTOS". That smarted.

So a guy named Tom Ball (later the Java Swing guy) wrote a Prolog script that somehow could just tell you if printing was working or not, and what to do about it. Never figured out how he did that. BUt our trouble tickets went from something like 60% printer-related, to noise. Just like that.

I remember after all these years, and try to make software foolproof. For the customer service folk, because they matter.

Post reply on HN