Author Topic: .NET development  (Read 1632 times)

PaulF

  • "World's Scariest Barman"
  • It's only impossible if you stop to think about it
.NET development
« on: 16 August, 2011, 09:13:32 am »
A question for the .Net developers.

My development team have just quoted me 75 days to develop a new screen.

It's for a user to create an order and will perform the same task as an existing form but be less cluttered. High level spec:

  • data entry form with about 20 fields
  • Validation on most fields is by searching for the string and seeing if the item exists in the database, functionality that is used in other parts of the system
  • Other fields are drop down or check boxes
  • 2 free text fields
  • One conditional field - if value is set to 'x' then display 2 additional fields
  • Some basic calculation

As all of the key functions, lookup and the calculations etc. already exist in the system I assume that they can be reused but the estimate seems somewhat excessive.

Anyone have a view on it?

Euan Uzami

Re: .NET development
« Reply #1 on: 16 August, 2011, 09:16:09 am »
75 days? Don't you mean hours?  :-\

75 days is quite reasonable. If they were to hard code it in assembly language.

Priddy

  • One of the "wrong sorts"
Re: .NET development
« Reply #2 on: 16 August, 2011, 09:20:49 am »
I would agree with Ben T, 75 days seems much more than you would expect for that amount of work. I have no idea what the rest of the system is like, but I would expect 10-15+ days depending on the amount of documentation that is written prior to any development and the amount of testing that is going to be done on it.

Chris S

Re: .NET development
« Reply #3 on: 16 August, 2011, 09:21:26 am »
I agree with Ben, 75 hours would be more reasonable - unless the back-end/DB code is particularly esoteric or there are other complications.

I assume this is an Agile style development, so they are handling unit and system testing too? Properly documented QA would add some to the workload - but even so, 75 days????  :o

PaulF

  • "World's Scariest Barman"
  • It's only impossible if you stop to think about it
Re: .NET development
« Reply #4 on: 16 August, 2011, 09:27:48 am »
Thanks, the back end is SQL server so not especially esoteric.

It will be agile development but the team is just moving to it so maybe they have a learning curve...

sas

  • Penguin power
    • My Flickr Photos
Re: .NET development
« Reply #5 on: 16 August, 2011, 09:38:04 am »
How well do you know them/they know you? They might be used to incompetent managers who are told something will take 4 weeks and reply OK I'll give you a week. Also is that 75 days of work, or 75 days including all the other stuff they have to do?
I am nothing and should be everything

Re: .NET development
« Reply #6 on: 16 August, 2011, 09:42:24 am »
If the developers are familiar with the language, I'd say that an Alpha version would take one-two man-days.  Then a man-day of checking functionality against requirements, and probably another man-day (but spread out over a period of time) testing integration with other functions.

Most of the work will be in the data retrieval - you say the libraries for that exist already.

I'm assuming that you already have the requirements and basic description of required functionality.
<i>Marmite slave</i>

Re: .NET development
« Reply #7 on: 16 August, 2011, 01:50:34 pm »
You don't say whether it is a web or winforms app (or silverlight etc...). Assuming it is a web app:

>> data entry form with about 20 fields

About 30-60 mins of typing html.

>> Validation on most fields is by searching for the string and seeing if the item exists in the database, functionality that is used in other parts of the system

So some type of autocomplete functionality. Almost trival these days with an async jQuery call and a static page method.

>> Other fields are drop down or check boxes
>> 2 free text fields
Method to fill the controls, method to read the controls and save the data...

>> One conditional field - if value is set to 'x' then display 2 additional fields
Again this is trivial these days.

>> Some basic calculation


Most time likely to be spent on validation, farting around with the CSS, and security (preventing XSS or SQL injection attacks for example). If you already have ways of dealing with that then it is very easy. 75 *hours* feels like an overstimate for me, never mind 75 days.
"There are proven ways; play on the certain knowledge of their superiority, the mystique of secret covenant, the esprit of shared suffering"

Chris S

Re: .NET development
« Reply #8 on: 16 August, 2011, 04:14:34 pm »
You need to make allowance for some proper QA. Unit testing, BVA, integration testing, UAT, as well as system test. Usually takes at least as long as the development, although this is largely ignored by management which is why most software is a bug ridden, largely disappointing experience, requiring a large amount of support.

Thirty years in the business made me cynical? Ho yuss...

Edit: If I had a tenner for each time I'd seen the "Bugger - only a month to release, cut short the testing by 75% chaps - we just don't have the time money" scenario, I could probably retire. Thankfully - this hasn't extended to the two safety critical things I've been involved with over the years; one involving things that fly, the other involving things that could blow up but you really don't want them to. In those cases, they ran massively over schedule and budget instead, but at least they worked.

Euan Uzami

Re: .NET development
« Reply #9 on: 16 August, 2011, 09:32:00 pm »
Thanks, the back end is SQL server so not especially esoteric.

It will be agile development but the team is just moving to it so maybe they have a learning curve...

We have been doing it for at least a year and are still on the learning curve. We regularly have arguments debates about how the principles of it should be applied to our particular situation.
One of the most important principles of it is that it is customer (stakeholder) driven.
What that means for the developers is that they should be working on what the customer has asked for and nothing more, and not what they envisage might be required in the future. Put simply, it isn't their place to envisage what might be required. That may sound obvious but it's very tempting as a developer to do just that, for various reasons. Even experienced developers can find themselves doing it.
What it means for the customer (stakeholder) is that they have to play their part in the development. They have to commit time to it on a regular basis. This takes the form of confirming how they want something and clarifying specifications. If they don't put this effort in then developers will simply speculate how something they are unsure of is to be, this speculation wastes time which is costly in itself, added to the fact they may get it wrong. You may think that your specification is simple and that it shouldn't need further clarification, but questions will arise as it starts being worked on - or at least they should if the developers are committed to delivering something that's going to please. You can attempt to pre-empt them all but that's tending towards the waterfall  model more which goes against agile. Questions raised may be minimal and if they are obviously the stakeholder's time investment will also be kept to a minimum, but one way in which our project suffers is that there is not the stakeholder availability there so we have to go on second rate stakeholder input or speculation - so just attempting to pass on my experience to you really in the hope you won't suffer the same pitfalls, of which there are many. I don't claim to be an expert on it however, really. There are whole books written solely on agile methodologies.