|
|
The poll left out usability, meaning can end-users actually use the masterpieces that we put together?  When I did the Norton AntiVirus 2000 UI, the first and foremost goal was better usability, since the old UI totally sucked. At the same time, I had to make the code maintainable, stable, and extensible so that future developers could create future revisions without me being there. Speed wasn't at the top of the list, because UI doesn't have to be blindingly fast, or heck even fast.  As long as you give good feedback to the user (usability again!) you're fine.
Luckily for me I had nearly a year for the project so I was able to do all that w/o many scheduling snafus.
--Mike--
http://home.inreach.com/mdunn/
Is history an illusion caused by the passage of time, or is time an illusion caused by the passage of history?
|
|
|
|
|
Yes usability is important as well ... who cares if the software is 100% stable, if you can't use it
(Yes, I am going back on my extensibility/flexibility tirade again!)
Its hard to get the usability just right during the first release of a software package (as was mentioned about Norton AntiVirus), so ensuring that the software is easily extensible allows the UI and other usability features to be easily updated and extended. So I believe that usability is important, but I also know that it will not be perfect the first time I release a product. Therefore I ensure that all aspects of the design are abstracted properly so that the software is easily extended and/or modified. It costs a lot more (time and money) to have to rewrite a software application from scratch, rather than updating an existing app (at least if it is properly designed )
Although I mention extensibility/flexibility as being the most important, it really is only the most important item from the poll. Actually I believe that proper architecture, design and planning are the most important... but do not get me on this subject or you will never be able to shut me up
|
|
|
|
|
As the owner of a software company, I can tell that from my expensive lessons in reality, the only thing that matters is that the program has a large potential market and is sellable.
Of course all profit can be blown on tech support calls and returns.
(Yes, I have been seduced by the dark side, and everything is clearer here)
'Capitalism Rules'
|
|
|
|
|
Why I voted for Maintainability:
IMHO, if your code is maintainable, you pretty much get most of the other stuff. The entire develop/debug/deploy process becomes less complicated. And lets not forget that in the "real world", programmers come and go (higher salaries, anyone?), so you need code that can be picked up by the new guy, or else you're in trouble.
Why I Lie:
Lets face it: you can't be this general about this kind of a topic! The most important factor should be deducted directly out of the product requirements. I can - and I'm sure many of you can also - think of products where stability is numero uno (think airplane navigation systems..). I can think of products where time to market is most important (money is no object), and some where cost of development is key. Again - the product and the customer are the major factors.
So I'm forced to call my vote a lie, because truthfully - I'd select "All of the above".
-Oz
---
Grab WndTabs from http://www.wndtabs.com to make your VC++ experience that much more comfortable...
|
|
|
|
|
|
I voted Stability, but that's a lie too, because you're right, it is maintainability. If you have a very easy to understand (and therefore maintain) system, then everything else comes for free. (Stability, extensibility, etc...)
If you don't have maintainability, as soon as you get a new coder on there trying to figure it out, you lose stability, extensibility, etc...
if your code can't be understood by someone with a few hours lifetime instruction in programming, then you need to fix it. the best code is the code that looks so simple you think anyone with half a brain could have written it - that's hard to actually accomplish. The worst code is the code it looks like it took someone with three PhDs in computer science and quantum mechanics to write it...
|
|
|
|
|
At my company the speed to market is often prioritized over reliability, even to the point of forgoing any kind of design process or testing (beyond what we as developers do). For our web team it is not such a big deal. If a problem arise they can quickly fix it, publish the page or update the component and the whole world is better.
My problem as one of the only desktop app developers, is we are held to the same standard of speed to market. Realistically however if a problem arise in one of our desktop apps, we have to fix the problem, create an install patch, distribute the install to 1000 offices around the US, get the clients to install it on thousands of all differently configured machines and hope that when the call us for tech support because the patch didn't work, that they are telling us the full story and not holding back some key information because it may be embarassing for them.
Is the rest of the world out there so caught up in being the first to market that quality is sacrificed? 
|
|
|
|
|
Unfortunately what you wrote is quite true. In most software companies "version early, version often" is their mandate. Although I believe that most developers try and do their best under this development model, there are several things usually against them:
(1) Having to build a product using a technology that they just started learning yesterday (lack of preparation).
(2) Having to show results to their managers almost right away (this cuts into proper architecture and design time).
(3) Lack of proper resources (equipment, books, man power, etc) ... a company must watch is spending you know
(4) Feature creep ... as the development cycle moves forward upper management/marketing always wants new features ... so more time is spent on adding in the features and testing time is cut, since the release date cannot be moved (of course)
(5) Lack of planning. Most developers do not like to plan, and I believe that many try and avoid proper planning either consciously or sub-consciously. Its more fun to code , but this lack of planning usually leads to improper design, and extended development times.
Just my opinion
|
|
|
|
|
I miss a coupple of items in the poll: Features and integration.
I'm coowner of a software development company, and I constantly hear our customers scream for features and integration with existing systems before anything else.
Christian Skovdal Andersen
|
|
|
|
|
If they scream, smack them !!!
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
If your code is Extensible and flexible, then adding new features (integration options) is easy.
I find that when developing new products that all aspects (cost, performance, stability, time to market, extensibility, etc.) need to be looked at, but at the end of the day extensibility and flexibility needs to be at the top. This may not be as important if the product life span is only one version. But in a high pace world of "version early, version often" then it is prudent for a development team to ensure that each successive version (major and minor) does not require a re-write. Also when a new product hits the market, no matter how much research was done the product will not be 100% perfect. So if the product is easily modifiable then it is easy to make the required changes fast, ensuring that clients are kept satisfied.
|
|
|
|
|
True!
I appreciate and refer to it as good opinion on my thread (New Biz on the Lounge) as well! 
Thankx!
"Socrates is a man. All men are mortal.
Therefore Socrates is mortal."
-- Aristotle (syllogism)
Cheers
Masoud Samimi Go!
|
|
|
|
|
I think you're not putting yourself in the shoes of the people that count: the customers. They're the ones who are trusting that you'll deliver something that meets their needs without crashing or acting eratically. That's why I think stability is the number one priority in any application. I can just picture it now, you ask someone to compare two similar applications and he says, "Well the first one crashes all the time but hey, the tech-support folks told me that its highly extensible. The other one? Well I don't know how extensible it is but I have yet to see it crash." Now, if you were that guy, which product would you keep?
Regards,
Alvaro
|
|
|
|
|
Everything is not black and white... just because I believe the extensibility/flexibility is more important than stability, it does not mean that you throw stability out the door. As I mentioned previously, one must consider all aspects of the project.
|
|
|
|
|
I agree that everything is important. But the survey was about which was the most important.
I'm just saying that from a sales and customer-satisfaction point of view, stability is it. Apparently most people who've taken the survey so far seem to agree. 
The second important thing to a customer is performance. He wants to be the one driving the application not the other way around.
The other points are more of importance to the managers and developers of the application, and are of little importance to the customer. As a developer I have to say that extensibility/flexibility is very important, that's why I like languages such as C++ and Java. Even more important, IMHO, is maintainability. If the code is well documented and easy to understand everyone will really appreciate it when the time comes to fix bugs or make enhancements.
Regards,
Alvaro
|
|
|
|
|
It is good to know what your customer wants, but it is dam hard to get your bosses to listen to them. I have worked for two company's last four years and it always comes to, if we can sell it them then we can milk them. Companys work on quatery bases, that means that if we can't make money for the product this quarter then we don't make it. I'm telling this because I work on a 20 year old product (still in dos) and the customer is asking us then the windows version is going to come out. The CIO doesn't want to spend a dime on a windows version because it means that we have to spend money on it that we will not get back until after 3 to 5 years. And in the mean time former employees are making a product what will blow us out of the water. So the money is number one every other thing is a bonus.
|
|
|
|
|
The quarterly profit problem is real, and sucks bigtime.
Clever Management does have an alternative though, Its called an accrued accounting system. What it means for you is the work you do now can be transfered to future quarters and years balance sheets.
The Downside to accrued accounting is only a few actuaries understand it !
So I doubt your management will adopt it.
But Consider joining the former employees !
Regardz
Colin
|
|
|
|
|
This is my point exactly. If you're at the point that you're putting your software out there for the public, then it had better be stable. If I get some software that crashes often I usually delete it and try to find something better. As far as the other choices go I think many of them can be taken care of through careful planning. Of course if you're anything like me you hate to plan. Personally I usually get a rough sketch of what I want in my head and then go for it. It works out in the end, but it probably takes longer and the code isn't as pretty.
|
|
|
|
|
Now, if you were that guy, which product would you keep?
The one that had the ad with the cute babe.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
