how much time should you spend on a feature?

Question

I'm currently working on a asp.net web form project by myself. How much time should i spend per feature, UI or backend...etc.? Currently i feel like i spend way too much time on little detail. Should i focus on the overall and just build the whole app and come back to the UI or little detail later on?

Answer 1

In short, as much time as it takes to make it work. No more. No less.

It's easy to be a perfectionist and put more and more effort into a feature as you think of ways to make it better. You need to stick to the requirements and not take it too far if you're ever going to finish something. If you have ideas on how to make it better, write them down. Then you can decide how much more work you really want to put into something.

As far as the "little details" are concerned, I think it's worth actually finishing a feature before moving on. It's hard to show an app to someone else and have to point out all the ways in which it's not done. I'd rather show someone one finished feature instead of a dozen half finished ones.

Answer 2

This is an impossible question, you can't put a cap on a feature, especially since there's no way to define exactly what a feature is.

I will agree that when I code C#, I often start dabbling with the minute details, especially in the early 1.0 days of .NET I would dabble with different ways to perform IsINT style checks (which are now build into the Framework).

This is one reason why I stick with a looser language, like PHP, it helps me just focus on the app, not the minute details of coding. The same can be said for Ruby.

Personally, I prefer to work from the top down. I often will make the entire UI first, this also gives me an easy way to show the app (even though it doesn't do anything yet) to managers or customers. Then I can slowly add functionality, still sticking with the top down mindset. At first I just write empty, verbose functions, and they make calls to lower functions. The lower I get, the more functionality there actually is.

Answer 3

This can't be quantified without knowing the details of the project. As a note, the UI is not a feature, it's a major part of any application. So don't leave it until last to be done with whatever time is left, but instead assign yourself some time to do it right.

In general, though, you should spend less time on the feature than the amount of time that it would cost the user not to have the feature. So if you want to add a feature that would save the user 5 seconds per use, and you expect them to use the feature 12 times per day, you would be saving the user 1 minute per day. That's about 5 minutes per week, or 4 hours per year per user. That should be your absolute cap on that feature.

As an addendum, the more users you expect for your application, the larger the amount of time you can spend on a feature. An application used by 5 people would not give you the same amount of time to spend on features as one used by 500 people. You can work out the time as a function of the user base (say, multiply time saved per user by the number of users / 100).

Answer 4

Well, a "feature" is an open ended thing. Some features can takes to hours while others can take 2 years. When you are coding and you want to make estimates or just do general planning, then you should break the feature into tasks. As a general rull of thumb, no task should take longer than 16 hours.

Answer 5

While more specifics are required for a firm answer, this is actually a strong case of why TDD is important. We mix both TDD and DDD in order to prevent this situation from occurring.

What happens is that we focus on the domain first, building the domain and eventually the business logic that goes with it. All of this is done with unit testing at every step of the way. When approaching a bottom-up approach like this, you can define the smallest granular pieces needed to make a unit test pass. Assuming that the unit tests are laid out properly, when you complete the unit tests, the code for the functionality is completed.

The UI we do last, because too often we see the UI driving decisions in the other logical tiers and layers of the application. Once we have met the business requirements, which can be tested with the unit tests written during development, we can hand off functionality to the design team to implement.

Answer 6

When looking at features and the time it takes, I look at my deadlines (either mandated or self-imposed) and take a scrum approach to it. I want to focus on developing features in ~1/2-3/4 of the time of an iteration and regardless of the time, I want to make sure that I get to the point where it's at least shippable.

If you find yourself focusing on the details a lot, make a note of what details you always get caught up in and see if there's a better way to spend the time in the future (making templates, snippets, learning something like jQuery or advanced CSS, etc.). If you find yourself adding things that weren't 100% required or are not really needed (regardless of impact), look into ways to focus on the core deliverable and not the additions.

Each feature will take a different duration. If you are concerned about the time it takes, focus on what you're working on and ensure that you are always on track for what you need to do. If you are still concerned, keep a log of everything you do, how long it takes, and how it relates to the project (if not documented directly to a spec). Doing such with cover your butt if your manager is asking why you are taking so long.

Answer 7

Make sure your app works... then add the bells and whistles. For instance, if I was developing an AJAX web app, I would first make sure my data sources worked as planned first, then apply all of the fancy stuff.

Answer 8

Time isn't necessarily the only consideration; be aware that there are other, fuzzier factors that come into play

Answer 9

Time vary from application to application.
I prefer to run the application & later on contribute less time to UI.