|
I was very close to choosing "Ease of use". But it's a chicken and egg thing - how will you know what's easy to use until customers actually see it? You can spend all the time in the world designing a UI that you think is great and easy to use. Then you get it out to the customers, and they use it in a totally different way than you expected. So that's when maintainability comes into play - you'll have to be able to change that program efficiently once you realize you got the interface wrong the first go-around.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Thing is, I do a lot of work (in my spare time) for several doctor's offices. They each use the same software. Not cause its the best even because they like it. They use it cause its the only piece of software that they can use for their specific notes. Its the only thing. Scary, but it kind of kills the "they have to like it" part.
|
|
|
|
|
|
Slow apps suck.
// Steve McLenithan
Cluelessnes:
There are no stupid questions, but there are a lot of inquisitive idiots.
|
|
|
|
|
Steve McLenithan wrote:
Slow apps suck.
What? Somebody mentioning Longhorn? 
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Slow machines suck
Perl combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski
|
|
|
|
|
Touche;P
// Steve McLenithan
Cluelessnes:
There are no stupid questions, but there are a lot of inquisitive idiots.
|
|
|
|
|
Get a bigger whip for your squirrel.
Software Zen: delete this;
|
|
|
|
|
Extensibility means:
1. I can fix speed problems by adopting new solutions
2. I can improve ease of use problems with new interfaces
3. Reliability can be improved swapping out crappy modules for better ones
4. Maintainability is implied--if it can't be maintained, how the heck can it be extended?
4. Good looking UI's can be added later on
5. Efficent use of resources can be dealt with when we get some usage information.
None of the other options covers all the bases.
Marc
Microsoft MVP, Visual C#
MyXaml
MyXaml Blog
|
|
|
|
|
but you would rather make you app easily extensible than easy to use?
if you clients can not figure out how to use it, and it sucks in their daily workflow, then dont care about extensability, they'll get someone else to make the app.
- Anders
Money talks, but all mine ever says is "Goodbye!"
ShotKeeper, my Photo Album / Organizer Application[^]My Photos[^]
|
|
|
|
|
I guess it depends on your definition of extensible. You are implying extensibility by coding standards - I understood it to mean it could be extended by the user or third parties... e.g., skins that can be changed, plug-in DLLs, stuff like that.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Wow! I was going to post that exact point. I agree completely. Anyone who doesn't understand that simply has not done much desk top development.
"In the final analysis, secularism is little more than another religion the first amendment should be protecting the American people against."
|
|
|
|
|
Well, as of the time of this posting, I'm the only vote for maintainability. I voted it because... no matter how well you think you konw your users... no matter how many features you put in there... your code WILL change. Period. Fact. And the original coders may or may not still be there to help out. So you have to be able to change it in a way that won't introduce a ton of bugs or totally break everything else.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Is it possible to start an iterative development process by starting with Maintainability? The "ilities" (Maintability, Scalability, etc.) are considerations that should be addressed throughout the design and development process; with desktop applications though, do you not have to start with what the user sees, in order to get feedback on what the application should do?
What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
|
|
|
|
|
John Kuhn wrote:
with desktop applications though, do you not have to start with what the user sees, in order to get feedback on what the application should do?
No, that should be done before you start coding.
|
|
|
|
|
Perhaps you should design, code, design, code, ..., N, N + 1... times during your development process, going back to the user(s) at the start of each iteration to make sure you're on track and they're in agreement.
What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
|
|
|
|
|
Yes, I agree, and practice this.
Dave
|
|
|
|
|
John Kuhn wrote:
do you not have to start with what the user sees, in order to get feedback on what the application should do?
No, you need to be thinking of maintainability throughout the design. For instance, what if you design your UI first, get feedback, and realize you got it all wrong? If you took maintainability into account when designing, you'd probably have accounted for the fact that the UI might change, and it would be easier. If you wrote the UI first and just threw everything else in, then you might have to gut your whole app when the UI needs an overhaul. (I've been there.  )
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Navin wrote:
For instance, what if you design your UI first, get feedback, and realize you got it all wrong?
It seems like that would only happen if you were working in isolation, and had never met with the user(s) in the first place. Certainly, in the design of a complex system, one would start with basic things, like identifying the business model, use cases, entities, items, things, scope, etc. However, after all of the abstractions have been captured an modeled, and the system's architecture is fairly firm, you have to show people something... and most people can't envision their future work flow by looking at UML diagrams, so you show them screen shots and sequences of events using "artifacts" that they can relate to. As I said earlier (or perhaps implied) maintainability is something we try to build in -- as a work habit as a coder -- and as an overall goal of system architecture.
Navin wrote:
If you wrote the UI first and just threw everything else in, then you might have to gut your whole app when the UI needs an overhaul.
That's definitely not what I was suggesting, but you are correct -- many of us have, in the course of our careers, designed, built and deployed small apps that were intended for a single purpose, that are easy to use, but even you, as the original author, have no idea why the @#$% you wrote it so poorly all those years ago.
What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
|
|
|
|
|
John Kuhn wrote:
It seems like that would only happen if you were working in isolation, and had never met with the user(s) in the first place.
You'd be surprised. Even major companies like Microsoft have to change their UIs from time to time (think VS 6.0 vs. VS.NET., or Windows 2000 vs. Windows XP) Beta testing, communicating with users and the like can give you a rough idea, but you never know for sure until your app is actually being used for its intended purpose.
Or, more commonly, you may have mistaken who your users really were going to be. Perhaps a completely different set of users started using your product and you didn't anticipate their particular needs.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Navin wrote:
but you never know for sure until your app is actually being used for its intended purpose
If that were true, all software would fail immediately upon deployment; I suggest that everyone should adopt an iterative design & build process, so that users are involved throughout. No one should ever go from talking to users, to building, testing and coding, straight to release, without talking to them and showing them what you're doing and letting them use it a bit so that you get feedback on what's right and what's wrong. And while it's true that no product is ever perfect at the time it's deployed, users give you feedback on what they SEE in front of them, and what they are able to do with it. If you get such feedback, you can immediately incorporate it into a an application in which most other factors were considered during the system design and architecture.
Navin wrote:
Even major companies like Microsoft have to change their UIs from time to time
And they do this based on feedback about products that were put through extensive usability testing in the first place.
Navin wrote:
you may have mistaken who your users really were going to be. Perhaps a completely different set of users started using your product and you didn't anticipate their particular needs.
If that happens, which I suppose it does, then the mistake was not that someone didn't work with users, but that the market analysis was bad and the wrong target market was identified... or in a corporate setting, that someone worked with executives & managers instead of the actual end-users.
What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
|
|
|
|
|
John Kuhn wrote:
Is it possible to start an iterative development process by starting with Maintainability?
It is definately possible. My favourite way is by doing test-first (or test-driven) development. If you haven't tried it yet, my recommendation is that you do. If you have ever been involved in a project lasting for more that a year and have seen the problems that arise, you will soon be blessed.
|
|
|
|
|
Do you think that test-driven development alone can ensure maintainabilty? Isn't it possible to produce code that, while passing through unit tests, etc., is still not intrinsically maintainable? As I suggested elsewhere in this thread, maintainability is a design goal and a good coding practice, but it is not the principal aim of developing a particular system, is it?
What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
|
|
|
|
|
John Kuhn wrote:
Do you think that test-driven development alone can ensure maintainabilty?
If you are using TDD the way it is supposed to, then it is my beleif that you will automatically end up with code that is easy to maintain. If it's not, then you'll do some refactoring until it is. Your tests will tell you that all things are working fine dispite of the changes. Refactoring is a natural part of TDD and if you have complicated code then TDD says that you should (not may) make it simpler.
I'm not saying that other options are not important. If you want to sell your application it better be easy to use! But as mentioned by someone else in this forum, if you have code that is easy to maintain you can easily accomplish all other things on that list of options. But if it's not easy to maintain you'd better do all other things on the list correct from the beginning.
|
|
|
|
|
I suppose that we will have to agree to disagree; not that I think testing is irrelevant, or that maintainability is not incredibly important; on the contrary, they both play an important role in my daily work.
However, that you will "automatically end up with code that is easy to maintain" seems like a leap of faith. Maintainability exists at many levels throughout the project life-cycle, and has as much to do with code comments, coding style, and testing (the role of the individual coder and his or her work habits) as it does with a high-level perspective on systemic design issues and the interaction between components of a system (the role of an architect).
Overall, it is my true belief that the latter of these two, good system architecture or design, is the most important factor, since everything else follows from that.
(Please also note that my earlier line of making small assertions, followed by a series of queries was somewhat disingenuous; I was simply trying to provoke a discussion, in which I succeeded, since we are still talking about these issues nearly a week and a half later.)
What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
