|
I'm talented at writing unmaintainable software, but... i'm not sure that helps... 
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- C hris L osinger, Online Poker Players?
|
|
|
|
|
|
But they "come and go" or get managers, so in the long run you need a tougher strategy as "talented people".
I believe you need a sustainable long term strategy which will be enforced via code reviews. 
Greetings from Germany
|
|
|
|
|
someone needs to be around (maybe an old programmer) or there needs to be some extremely excellent documentation that tells about all the nuances for building and delivering software. Maybe bits and pieces about old O/S's that someone needs to know in order to save days or weeks figuring out why they can't build or fix a deliverable that runs on some old O/S etc.
The original project may of depended on a certain level of toolset, maybe something that isn't even sold anymore, that perhaps even was tweaked or built differently from what the original vendor delivered.
It is the little nuances that might really hurt.. and of course it may be partially developed in a language that isn't very much taught anymore.
|
|
|
|
|
jeffkish wrote: there needs to be some extremely excellent documentation that tells about all the nuances for building and delivering software
And those little hidden configuration issues. The documentation should also encompass a rich set of knowledgebase which keeps building itself along with the project.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
Yesterday is a canceled check. Tomorrow is a promissory note. Today is the ready cash. USE IT.
|
|
|
|
|
"Requirements refinement and rapid prototyping.
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. "
No Silver Bullet[^]
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
