While I agree on some of your points, I think other points are not as "valid".Peter Wone wrote:Why don't we build great software?The last item is key to understanding the success of Textpad. Programmers have a very clear and complete idea of what constitutes a good programmer's editor. We understand what is frippery and what is crucial, and we understand how the software will be used. This is what underpins the success of Linux as a server OS and is also the reason that it is rather less stellar as an OS for end users.
- Nebulous specifications.
- Mutable specifications.
- Limited budgets.
- Design by committee.
- Limited (absurd) time-frames.
- We don't really understand the problem domain.
If you, as a developer, are in contact with the customers/useres of the to-be-developed software, you can cope with 'Mutable specs'. May be it's not easy, may be to don't like it - but you can.
You can cope with neboulus and mutable specs, if you have a thight contact to the end users of the software.
If you have achieved this, you'll have a good chance to understand the problem domain - by talking to people who do so: Your customers and/or users.
BTW, as I'm currently looking for a new job, I think it's really stragne that so many companies more or less strictly insulte the developers from the customers. Sometimes I was told that this would provide the 'loose coupling' known from oo programming. ?!?
So loosely that one side wonders why the other side produces hard to use products.
A Limited budget is just one of the 'hard' constraints. Others are: Available time, product quality, number of features. The problem is (IMHO) that way too often developers (or development teams) are forced to work under constraints that can#t possibly work out. It's impossible to set all of these (as a manager, customer or whatever may dictate the business).
As a software developer you should always have (at least) one of the prime factors under your control.
That way you might be able to devilver a product on time, in budget and at the required level of quality - but probably not with all the features on the wishlist.
'Design by commitee' is often a synonym for 'bad design'. So much is true. Design by team sounds mucht better (to me).
Happy developing - anyway
Stephan