|
efficient / fast software development
Managers try to get inexpensive software development by sending the work offshore.
However, less expensive software development can be done in the US, if we work more efficiently / faster.
A lot of people discuss methodologies, design patterns and other things, but I have rarely seen discussions about topics such as:
- how to develop software faster
- how to DESIGN a program in order to get it done faster while maintaining good quality
- how to organize a team in order to work more efficiently
It's not like there is no discussion, but the existing discussions don't focus on the speed of development.
Is there any web site that discusses fast software development?
MX
Monday, November 17, 2003
1. Rapid Software Development by Steve McConnell will tell you everything that is known about this subject.
2. Developers don't need to be faster. They just need to provide better products and service than their competitors. As it is, an american team will certainly deliver a product of equivalent quality substantially faster than an overseas team. Speed is not one of the advantages of offshore development and never will be.
King David
Monday, November 17, 2003
> Developers don't need to be faster.
What I wanted to say is that fast also means inexpensive.
Let's say a developer is paid $ 60K per year.
If this developer gets a certain software done in 6 months, then the employer of that developer got the software for $ 30K.
If the same developer learns some techniques and gets the same software done in 4 months, then the same software has costed the company only $ 20K - that is, the employer paid 33% less for the software!
Of course I'm simplifying a lot here, because for each developer, the company pays much more than his wages, but I think I made my point, which is:
Faster development also means less expensive development.
Please note that I'm not advocating lowering the quality of the software, but finding a way to develop it faster, at the same quality.
MX
Monday, November 17, 2003
Totally unscientific conclusion by Philo:
#1 difference between successfully offshored projects and average "overpriced" US development?
Clear, specific specifications.
Philo
Philo.
Monday, November 17, 2003
Don't forget local developers have an inherent speed advantage of shorter and thicker lines of communication. There's a qualitative as well as quantitative advantage.
For example, most people believe it's vital for the developer to watch the client trying out early versions. An onshore rep of an offshore team isn't the perfect alternative.
anonymous
Monday, November 17, 2003
"What I wanted to say is that fast also means inexpensive."
Oh dear. Seriously, read Rapid Development. One point it proves overwhelmingly is that faster is almost always more expensive. Sometimes much more expensive.
King David
Monday, November 17, 2003
"Clear, specific specifications."
mmm...
how about this spec:
> We want you guys to port Xpress 5 to OS X. Just do a straight port, don't add any new features.
Seems pretty clear to me.
King David
Monday, November 17, 2003
See the top two paragraphs on page 114 in Rapid Development -- that way you can read it at the bookstore if you don't want to buy the book.
King David
Monday, November 17, 2003
"how about this spec:
> We want you guys to port Xpress 5 to OS X. Just do a straight port, don't add any new features.
Seems pretty clear to me"
Yes. Xpress 5 is the specification for the OS X version. What was your point?
Monday, November 17, 2003
MX, ever tried writing corporate mission statements? You'd be good:
"We're focussed on delivering the best high quality software faster and cheaper, and also exceeding your expectations."
.
Monday, November 17, 2003
Do I have to spell out my point?
v6 was the os x release version. v5 was the spec. the spec was exceptionally clear and yet the project failed, so i guess having a perfect spec doesn't solve all your problems
Monday, November 17, 2003
King David, I'm really serious - take some logic or debate courses. You *really* need them.
"The major killer in the US today is traffic fatalities - if we had safer cars then a lot of people wouldn't die"
"But I know some people that died of cancer. So your point is completely wrong, isn't it?"
Geez.
Philo
Philo.
Monday, November 17, 2003
Just to a straight port of XPress5 is a terrible specification.
Didn't these guys just lay off all there developers, deciding they didn't need them because they were going to outsource? That was the mistake.
Sure you have the running application, sure you have the source code, but there is a lot more knowledge needed to actually make that port.
There are 2 places you can have this knowledge:
1) In the heads of your developers. This is the default location. If you hire smart developers and set them to work they just remember it all as the go along.
Unfortunately, while aquisition is cheep and painless transfer is not. Just transfering the knowledge from one generation to the next in the same office is hard enough.
If you do something foolish, like get rid of all your developers then you loose all of that knowledge. They'll probably go off and start their own software house the will long outlive yours.
2) Written down in documents. This is hard work, because you need to have systems in place to document it all in clear specifications.
However, once done right it can make knowledge transfer much easier. Its not really the documents themselves that give you this benefit, its the systems and processes you have to put in place to get the documentation working. Its the approach to developing you must take.
For outsourcing to work you have to take this approach. You have to have all kings of systems and Q & A in place, otherwise seemingly simple tasks like porting to the latest OS version will turn into a complete mess.
Ged Byrne
Monday, November 17, 2003
Philo - 100% correct "Clear, specific specifications."
In our company they have drastically reduced the cost of development teams by offshoring. Of course, they have drastically increased the time and cost of requirements analysis to meet the needs of the completely autonomous development team. I think a strength of the employee programmer is being able to dump vague requirements and get something close to what you wanted (if you consider this a strength).
m
Monday, November 17, 2003
Guys, an actual working application with the source code is the ULTIMATE specification. You can't get any better than that.
Like, get a grip ya weenies. Got a problem wiht me? Let's take it outside douchebags! Gonna be doing some travelling for business next month and I can take any or all of you on in any of the following cities you care to during December:
San Jose
Albuquerque
Cincinnati
Minneapolis
New York
Washington DC
Atlanta
Let's get it on!
King David
Monday, November 17, 2003
Point is, and I'll say this real slow so you can understand me, that you can have a perfect specification and it won't do you jack shit if you got crap developers.
King David
Monday, November 17, 2003
"I think a strength of the employee programmer is being able to dump vague requirements and get something close to what you wanted (if you consider this a strength). "
I do consider that a strength. Should we try to get rid of vague requirements? Absolutely. But it's also nice to know that you can say "Do this." and I know enough to also "Do that" and maybe even "This other thing" and be right more often than I'm wrong simply because I've done similar things for you before.
Ron Porter
Monday, November 17, 2003
>Guys, an actual working application with the source code
>is the ULTIMATE specification. You can't get any better
>than that.
That's ridiculous.
An implementation is not the same as the specification. A good spec says how things _should_ be, and (preferably) _why_ they should be that way.
A working app with source code doesn't tell you either of those things - it simply says how things _are_.
I suppose the many bugs that will exist in the implementation are part of the spec?
Please.
Mike Treit
Monday, November 17, 2003
>>I suppose the many bugs that will exist in the
>> implementation are part of the spec?
Almost certainly. You can bet that for every long-standing quirk in the application there's an important customer that likes it to work that way and will whine until you "unfix" it :)
Andrew Reid
Monday, November 17, 2003
You guys have a tough row to hoe if you want to prove that comprehensive specifications are more important to project success than hiring good developers. A tough row. got any empirical data on that?
Regarding the Code Is the Design, well the Code is the Design.
King David
Monday, November 17, 2003
I don't think anybody is arguing that King David. I think everybody is pretty much stating if you had to pick one, go with the developer, but in every case you would get better results with good specifications. You shouldn't always have to rely on "heroics" to get the job done.
m
Monday, November 17, 2003
Well I guess there's no argument then. I have no a priori problem with either good management or well thought out specifications. The entirety of my beef is the statements that either of those are the #1 most important predictor of success in any development project. I say that, all factors considered, the skill of the developers continues to be more a strongly correlated success factor than management, specs, development tools, computer speed, office lighting, or doors that close.
King David
Monday, November 17, 2003
Give me the best developers in the world - Chris Sells, Joel, Stroustrup, Torvalds, etc. Give me them and an unlimited budget.
As the project manager I can guarantee I can get the project to fail inside of three months.
- Able Project Management
- Strong Developers
- Good specifications
Any one of these can sink a project all by themselves. If one factor is bad enough, there is no way the other two can save it, no matter how good they are.
Now, and think carefully here - which one of those three has positive control over the other two?
Philo
Philo.
Monday, November 17, 2003
MX:
What you're looking for is Extreme Programming.
http://c2.com/cgi/wiki?ExtremeProgramming
It's all about taking good software development practices and turning the knobs on them up to 11.
More specifically, by using Test Driven Development you're saving a substantial amount of time on a project because you're doing your testing up front. No more interminable "testing & bugfixing" phase at the end of the project, or not nearly as much of one. That can translate into some real savings even if you don't do any of the other XP practices.
Combining it with the other XP practices amplifies the effect.
Chris Hanson
Monday, November 17, 2003
Philo, I'm going to have to disagree with you on the "if one factor is bad enough..." comment. I'm sure we've all worked on projects where there was NO spec, and NO project management. I know i've done lots of those. I'm not saying that they can't cause major problems, and that if done right, they wouldn't improve things by tenfold. But I really do believe that its the developers that make or break a project, and not other factors.
Fast software development? I work in a place thats blazing fast. I think there are lots of teams that are quite fast. I'd say we're so fast management can't keep up. They've begun to ask for features, and once implemented, they didn't even know what direction they wanted to take the project in. It seems like your looking for a magic solution. I have one:
HIRE GOOD PEOPLE!
There, its not hard. You hire "superstars", and pay them a lot, and I would bet money they could produce code up to ten times faster then your average "business developer".
Vince
Tuesday, November 18, 2003
> Like, get a grip ya weenies. Got a problem wiht me? Let's take it outside douchebags! <
Philo, it looks like you're wrong, King David has all the argumentation skills he needs.
www.MarkTAW.com
Tuesday, November 18, 2003
"An implementation is not the same as the specification. A good spec says how things _should_ be, and (preferably) _why_ they should be that way."
The requirement suggested by Philo was a port of a particular piece of software to another OS. If you want ported which is different then you are for sure going to have to spec out what those changes are, otherwise it should function exactly the same as the original down to colors, shortcuts, and everything else).
Tuesday, November 18, 2003
MX - The idea of competing on a cost basis strikes me as being a bad idea.
1. Any improvements to methodology that could decrease costs to American developers would likely be adopted overseas, nullifying that innovation.
2. By accepting a "churn out code" factory style mentality, you're reinforcing the idea that code should be done as cheaply as possible - which is the reason businesses go overseas to begin with.
www.MarkTAW.com
Tuesday, November 18, 2003
> I'd say we're so fast management can't keep up. They've begun to ask for features, and once implemented, they didn't even know what direction they wanted to take the project in. <
So does the project take longer or shorter this way?
"The project should take six months."
"Management doesn't know what they want, add three months."
"The developers are mediocre, add three months."
At the end of 9 months, what's the difference?
I agree that a good tailor fitting a suit on someone who doesn't know if they want blue or gray will ultimately produce a better suit than a bad tailor fitting a suit on someone who knows exactly what they want, but time added is time added.
Also, I think the main question here is how can the average (this is a key word, i'll repeat it: average) American developer "compete" with their overseas counterpart - i.e. not lose their job.
Whether or not that programmer has been given good specifications or not, it seems, is not the issue. It's whether or not Americans can compete on cost.
www.MarkTAW.com
Tuesday, November 18, 2003
Vince,
A project can do great with NO project managers and NO specification.
However, what can a good developer do against BAD program managers and BAD specifications.
The developer is bound by the project manager and the specification.
What great software did Joel produce at Juno?
Ged Byrne
Tuesday, November 18, 2003
http://www.joelonsoftware.com/articles/fog0000000072.html
Ged Byrne
Tuesday, November 18, 2003
Yeah, reference the scripture, Ged. That'll shut him up.
There is only one true Joel!
Tuesday, November 18, 2003
Mark the bits you don't understand and I'll try to explain them to you:
"A public forum for open discussion of topics raised on Joel
on Software."
Ged Byrne
Tuesday, November 18, 2003
Average american developers can't compete with top indian developers. There's no way around that.
Top notch developers are guys who can envision, build and market a winning and beloved application from scratch.
Developers who aren't top notch are doomed. If you aren't a top guy, just like if you aren't a major league baseball player, then you are not goingc to make a career of it in the long term. Sorry. The competition is too agile here. You're doomed and that's all there is to it.
The question is whether or not top notch western developers can compete with top notch indian developers with identical abilities who are willing to work for peanuts.
i say the answer is maybe.
King David
Tuesday, November 18, 2003
> Average american developers can't compete with top indian developers. There's no way around that. <
I'll agree with that. Conversely, can the average Indian developer compete with top notch American developers?
So the original post looking for a magic bullet to solve the American developer's problems - a super methodology that couldn't be copied overseas - unrealistic.
I'm not sure your baseball analogy holds though, pro ball is a very specific thing, and by definition there are a limited number of seats available. Baseball also doesn't suffer from much overseas competition, and the imported players don't necessarily earn any less than the equivelant American ball players.
There will continue to be American programming jobs just as there are jobs for NY drivers in a sea of Pakistani cab drivers.
www.MarkTAW.com
Tuesday, November 18, 2003
The comparison I wanted to make was that in pro sports, only the top guys have a chance to make a living at it.
King David
Tuesday, November 18, 2003
And I'd say that although a average indian developer can't produce better results than a top notch american developer (remove country of origin labels and the statement is still valid), that won't stop some companies from trying and the result will be low quality products and failed projects. The reason for all this is because there is such a huge difference between average and top notch in the field of development.
King David
Tuesday, November 18, 2003
"1. Any improvements to methodology that could decrease costs to American developers would likely be adopted overseas, nullifying that innovation."
Not necessarily. If the improvement requires discipline, up-front expense, or skill and experience, many will be unwilling or unable to follow it, especially if it means changing the way things have always been done. For example, some companies don't even use version control, and do no code reviews whatesoever. Still, these obstacles will mean many American companies also won't adopt the new methodology.
--
Tuesday, November 18, 2003
Extreme Programming, if you're following it to the letter, involves having the entire team in one room and having a full-time on-site customer.
Customers tend not to want to send people off-site for extended periods of time, since the type of people who act as the customer representative on an XP team generally also have other work to do.
Generally this means that the team can't even be in a different part of the same state than their customer, much less on the other side of the planet. Being located in the same city is best.
One good end result is that this type of work encourages the growth of dynamic local software industries everywhere, not just in a few concentrated areas.
Chris Hanson
Wednesday, November 19, 2003
i realy want the solution for this issue.
How to make the softwares faster?
is it..
change in developers to top notch.
change in methodology/ tools
change in attitude of the developers
or some thing else?
dky
Wednesday, June 2, 2004
 Recent Topics
Fog Creek Home
| 
