|
Accurate requirements is most definitely the answer, unfortunately I've never seen it happen.
Faith is a fine invention
For gentlemen who see;
But microscopes are prudent
In an emergency!
-Emily Dickinson
|
|
|
|
|
This only helps the initial creation. It doesn't help if the client changes its work flow dramatically by moving out of town.
And by the time you get be to supporting it the intial requirements have no relationship to the current function - except for the name of the application.
Lena
|
|
|
|
|
LenaBr wrote: And by the time you get be to supporting it the intial requirements have no relationship to the current function
Then those requirements weren't "accurate", and prove that *accurate* requirements is propbably the best answer for this question.
I've worked with many "talented developers", and I wouldn't want to maintain their code.
|
|
|
|
|
Yes but...
Requirements can only be accurate at a given point in time. In our "fast-changing world" how can anyone possibly imagine what the requirements will be in 6 months (or worse) 2 years time? Changes in company management, policies, marketing strategy, etc. can all lead to minor/major changes in requirements.
With your solution, you have to update your requirements as you go along, which as you pointed out means they were inaccurate in the first place...
=> "Accurate requirements" is just an oxymoron, really 
Elinor
|
|
|
|
|
well changes in the application would be to add new functionality or alter some. so the architecture of the application should be able to accomadate changes and such architecture is the basic requirement now days so requirements are very important
|
|
|
|
|
Very true here.
I have inherited an application which was written 10+ years ago in VB3 (by about 5 different developers) using data from a mainframe ERP system. In 2003, I ported it to VB6 and changed it ever so slightly to interface with a new ERP system. However, the initial function of the software has not changed and we were able to make the ERP switch seamless for our customers, without a total rewrite (nor did our back-end database design change much either).
I attribute that to Talented Developers (in this case me :->)more than accurate requirements, since there is no way the original design team could have anticipated where we are today.
-Wayne
|
|
|
|
|
Yeah you are right wschalk, in your case Talented Developers can solve the problem of mantaining and in some cases applying reengineering to a existent Application ...but If we talk about a new Project with a proactive Analyzer and/or architect Accurate Requirements become the most important phase to avoid the nightmare of Change Process... sorry for my english 
|
|
|
|
|
Agree, most of the brutal hacks I've come across (or been forced to perform) have resulted from customers changing specifications and requirements halfway through a project. By this stage the architecture is pretty much set in stone, so changing that is out of the question, it creates hard to read, difficult to debug and horrendous to maintain code.
who knows what evil lurks in the hearts of men?
|
|
|
|
|
Steve McConnell compares various methods and their efficacy in finding code defects. He cites a research which indicated the following rank:
1. Large Scale Beta Testing
2. Code Review
I forgot the others. But code review is extremely important even more important that unit tests. In my experience, code review can catch subtle mistakes which may be missed by normal testing and even unit tests.
Yes, talent is important but I will not think of it as the most important thing. In some cases talented developers may produce worse code.
Co-Author ASP.NET AJAX in Action
CP Quote of the Day:
It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
|
|
|
|
|
Rama Krishna Vavilala wrote: Yes, talent is important but I will not think of it as the most important thing.
Talent is maybe a wrong word, but I would say that the quality of people involved in the project (managers and developers) is much more important than any procedure or tools they may use.
|
|
|
|
|
Yes good point:
"People before processes";)
I was thinking more in terms of programming talent. I have seen good developers produce unmaintainable code and average developers produce good maintainable good. Nevertheless, I fully agree with your point.
Co-Author ASP.NET AJAX in Action
CP Quote of the Day:
It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
|
|
|
|
|
When it comes to CodeReview, I feel this checklist from Macadamian is a bit comprehensive:
http://www.macadamian.com/index.php?option=com_content&task=view&id=27&Itemid=31[^]
Till sometime back, they were also offering a Visual Studio AddIn which would help you to archive CodeReview comments in the file itself but I am not able to locate the same now. If you could locate the URL, please do share the same.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
Yesterday is a canceled check. Tomorrow is a promissory note. Today is the ready cash. USE IT.
|
|
|
|
|
These are all so entwined as to be inseparable for a successful, maintainable product. The one thing that's missing though, not even captured in documentation, is the "knowledge" that went into the decisions. Why is the architecture this way? Why are there certain requirements? What were the decisions that led up to the current soutions?
I've found, over the years that this is such important missing knowledge, that even with the best intentions, the most skilled people, etc., that not having a roadmap of where the project started and the paths and decisions it took, leads eventually to the degredation of the project as people, quite innocently, repeat mistakes.
It's actually the primary reason why I set up a wiki and a blog for a client--so we can have a knowledge base outside of the typical design documentation, and a chronology of experiences, that can hopefully serve as guidance to folks who will be maintaining a product that is intended to be around 20+ years from now.
Marc
|
|
|
|
|
Marc Clifton wrote: The one thing that's missing though
Yes. I read an article in my first years where the author said he created a Project Diary document for every project where he put that sort of information. I have been doing that ever since. It's invaluable. It's where all the stuff goes that is not captured by formal documentation. You can't possibly remember all that stuff.
|
|
|
|
|
From Competent Management all other things flow. They will hire competent developers, ensure on going training, code reviews, that the documentation is in good shape and so on.
|
|
|
|
|
Yes, but 'competent management' is an oxymoron, is it not?
Software Zen: delete this;
|
|
|
|
|
Colin Angus Mackay wrote: From Competent Management all other things flow. They will hire competent developers, ensure on going training, code reviews, that the documentation is in good shape and so on.
Exactly, this is the most important thing. After the four years of hard struggle a software house vanishes. The only flaw was the lake of Competent Management.
________________________________
Success is not something to wait for, its something to work for.
|
|
|
|
|
|
Competent Management IS rare. But Colin Angus Mackay hit the reason why this is the right choice.
|
|
|
|
|
Agreed. Competent management also understands that leadership isn't always "from the front," and will defer to and/or listen to competent developers and subject matter experts. All other options on the list (accurate requirements, code reviews, training, etc) become realities or wishful thinking depending on what is happening with management.
-Jeff
|
|
|
|
|
Competent Management...is that like a unicorn?
|
|
|
|
|
Talented developer’s minimally carry the following attributes.
1) Consistent documentation and coding style thought out single or multiple projects.
2) Ongoing developer training where it’s personal time or company time.
3) Regular code reviews and refactoring.
4) Developing solid architectures and consistent solutions making maintenance a breeze.
5) Being a team player sharing ideas.
That’s my 2 cents worth 
Wisdom is often meant as the ability and desire to make choices that can gain approval in a long-term examination by many people.
|
|
|
|
|
Manager : "Hey! don't keep on saying so many BIG words like infrastructure, architecture, design-pattern, code-reusable, multi-layers and etc.... I just want this application within two weeks..... "
Talented developer : "Yes, sir"
Every developers used to dream about cool things and cool projects.. but take the survey and see how many developers are working for uncool projects....
|
|
|
|
|
Hey! To me any project is fun it`s the design i favor .
Its not what you build, its how you build it!  ;P
-- modified at 4:04 Monday 5th November, 2007
Wisdom is often meant as the ability and desire to make choices that can gain approval in a long-term examination by many people.
|
|
|
|
|
Manager :"And make it look sexy" and "Just write it and hand it over" "Why are you wasting time with all that testing?"
"It doesn't look sexy enough - change it"
Developer "But I haven't finished testing the data flow"
Manager: "It doesn't look sexy enough - change it"
Manager: "Why are you behind schedule? and it doesn't look sexy enough can we make it look like Google?"
Developer : "Can I please finish testing the data?"
Manager: "No we are implementing it next week, It doesn't look sexy enough can you make it look like Yahoo?" Does "view page source" "See just code it like that, it can't be that hard"
Manager during demo to client:"Hey maybe we can do it differently, lets make it look like Facebook and ....."
Developer :searching on monster.ca .....
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
