|
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 .....
|
|
|
|
|
 Sounds like a everyday song.
Wisdom is often meant as the ability and desire to make choices that can gain approval in a long-term examination by many people.
|
|
|
|
|
|
With out good specs and requirements documentation the mos talanted developer is useless.
When prediction serves as polemic, it nearly always fails. Our prefrontal lobes can probe the future only when they aren’t leashed by dogma. The worst enemy of agile anticipation is our human propensity for comfy self-delusion. David Brin
Buddha Dave
|
|
|
|
|
David Lane wrote: With out good specs and requirements documentation the mos talanted developer is useless.
You can't say that in general.
Tight specs and requirements "brought down from mount Sinai" (meaning fixed and unalterable as if given by God himself) can kill any project.
Most of the time, the users do not know what they wand, end even less how they want it.
And how could they know?
They are just now coming up with their ideas. No one did this workflow before (or else your project would be a waste of time, as the users would be better off using the existing software).
Their ideas are naturally vague, sometimes ill devised and often without knowledge how much work a feature would cost.
Several iterations could be needed to get to know which workflows are feasible and desireable.
And that can not be thought out in advance.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
It goes without saying 
WPF - Imagineers Wanted
Follow your nose using DoubleAnimationUsingPath
|
|
|
|
|
I agree, but would also add the competent managers. It is all about people, after all
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
