|
In a practical sense this is critical in my opinion.
I have several times been given a large lump of code by a client, to bug fix, or refactor or redesign, and it is the way the code is written that gives me the biggest problem.
The other problem is that the often talented developers who wrote the code have often moved on, taking their talent with them and are so of no help to me!
|
|
|
|
|
Kevin Miles wrote: it is the way the code is written that gives me the biggest problem
What specifically is it that gives you a problem?
I ask my developers to stick to a very rigid coding style that defines everything from casing, comments, how we place review marks all the way down to region separators and alignment of elements. Some developers I've worked with over the years don't mind it and some, well, feel it is less than optimal and inhibits their abliity to write code the way they want to.
The reasoning is this, though: if we sell some code, get another developer onboard, or need to revisit code that's 2 years old and everything, everywhere, has exactly the same style, then reading and reviewing should (in theory) be a lot easier over time.
I just wonder what others have found...
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
My situation is that I work freelance, so quite often by the time I turn up, several years of more or less uncontrolled hacking has taken place, by various different people, in different styles.
Often there is very little in the way of observed coding standards. I see C++ written like it is C, or like it is some kind of mathematical shorthand, (when dealing with code from the pure maths/physics types).
Usually these people have moved on (or been promoted out of the way where they can cause less damage).
In this position I can sometimes be frank to the current manager, but I can't rock the boat too much. So I just have to make do.
Anyway, that's why I say it's the style(s) that is often the problem, in my situation.
|
|
|
|
|
I agree that you need to impose coding standards, but I think it's often the case that you can get bogged down in details of formatting and punctuation and lose the overall point, which is that the source code is an engineering document. I think it is better to set an overall goal that the source should be a clear and concise description of how the programme works, and control this by reviewing the code for clarity before it is integrated.
|
|
|
|
|
All commercial code should be peer reviewed hence the reviewer should impose some standard.
|
|
|
|
|
If none of the members of the group communicate well, the product will be unmaintainable.
Marketing must communciate feature requirements, coders must comment in a meaningful way, etc.
Not that all the communication is verbal, but what I find to be most troubling always comes back to lack of proper communication. No comments, no documentation, not enough time to tell someone what is going on, etc.
|
|
|
|
|
|
The weekly regular candidate was almost forgotten this time. Thanks for reminding and inviting him to the survey anyway. 
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
Yesterday is a canceled check. Tomorrow is a promissory note. Today is the ready cash. USE IT.
|
|
|
|
|
Competent management... no doubt about it...
Only with a competent management you can have the knowledge to build a team of competent developers, can have a good architecture to document  , can squeeze customers for accurate requirements, can know about code reviews and the proper time gap between them for each project, can evaluate team members and can establish ongoing developer training for each individual depending on he's needs.
So, I just mentioned all the point on this poll and all depend on a good and competent management to succeed.
|
|
|
|
|
Do you belive this will ever happen? 
Greetings from Germany
|
|
|
|
|
The lack of a "head" on a project is, for me, the beginning of everything else that will go wrong.
Most projects have someone that call himself the "Project Manager" but in most cases he is everything or is just the face of it.
In my opinion every project must have one person that knows about every aspect of it, he must participate on every architecture meeting and most importantly he must know about what he's being told.
Sure he can't do everything alone, he must be able to delegate tasks but the final word is always his.
Only this way we can have a controlled project that will stay on track.
|
|
|
|
|
Rubbish!
My team consists of one manager, one designer/architect, one developer, one tester and one documenter. They are all me. All of them call myself a software engineer.
It's the software engineer that matters.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
I'm talking about teams not prison cells...
You can call yourself whatever you want from the roles you have to play when you work alone.
If you're working on a medium sized team with lets say... 12 individuals, what would be the most important role for you?
The Architect? Why? Everyone is as important in a team, that's why it's called a TEAM.
The responsibility of the project manager is to build that team so it works as a team not as separated individualities and this is the beginning of everything else that will come.
|
|
|
|
|
AlexCode wrote: You can call yourself whatever you want from the roles you have to play when you work alone.
That's bordering on Soapbox material! 
:josh:
My WPF Blog[ ^]
Without a strive for perfection I would be terribly bored.
|
|
|
|
|
Still being "bordering on Soapbox material" it's irremediably... true! :->
P.S.: Why don't you call yourself CEO? 
|
|
|
|
|
AlexCode wrote: P.S.: Why don't you call yourself CEO?
I prefer CFO. (no, not "financial") 
:josh:
My WPF Blog[ ^]
Without a strive for perfection I would be terribly bored.
|
|
|
|
|
A paycheck...nuff said
Steve
|
|
|
|
|
|
I tried dipping my employees checks in bacon grease. It didn't help and the banks complained.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: the banks complained
You rather gave them some real business. Isn't it? Are they that much lazy to shirk responsibility and complain on you?
Ennis Ray Lynch, Jr. wrote: I tried dipping my employees checks in bacon grease. It didn't help
I admit. Whilst the management can take the yeoman efforts to satisfy the employees, the employees should also consider thier responsibility from inner self. If the mental attitude of employees is just deriving sensual pleasures, wasting thier time in unnecessary unproductive activities, there is the risk of ship capsizing. An organization is typically like a family. It needs a healthy cooperation accompanied by free unadulterated affection and love for each other for mutually rewarding benefits.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
Yesterday is a canceled check. Tomorrow is a promissory note. Today is the ready cash. USE IT.
|
|
|
|
|
In my own experience the single factor that made the biggest impact on the maintainability of a large project was the implementation of unit tests. It effectively provided documentation on how the code was supposed to work, and allowed the code to be re-factored and restructured without breaking it. Consequently the architecture and coding style could be migrated from 'big ball of mud' to something more elegant and beautiful.
Keith Barrett
|
|
|
|
|
Heck, having good test coverage, even if it's implemented as black-box tests, can make a world of difference in giving developers the confidence to go in and change things for the better. When you're continually working for the absolute smallest changes to existing code, it isn't too long before the whole mess just collapses.
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?
|
|
|
|
|
The problem with unit tests, is they are the first thing to go when something needs to go. Unit tests are fluff, ultimately, and while they often provide a developer benefit, unless your a stellar Agile house where upper management fully understands the value of tested code, they are just extra time (and therefor extra money). Nothing can surpass a talented development team full of diverse specialties...one way or another, the team will figure out how to develop maintainable code while still supplying deliverables.
|
|
|
|
|
Yes, writing and maintaining units tests is an overhead (about 100% in my experience) and consequently they look like a good candidate for cutting when timescales get tight. But what you have to present to management is the cost/benefit analysis. That is, say something along the lines of "yes I can do this in half the time, but I will be only 10% confident it will work, versus 90% if I include unit testing".
Actually, it would be very useful to have more quantative figures to back up this argument. The above numbers are just my questimates. Has any one done any statistical studies to see what the effect of unit testing is on software quality and timescales?
Jon Rista wrote: Nothing can surpass a talented development team...
Well I'm not sure I agree with that. I've worked on a lot of teams of very talented people, but ultimately they are not in control of requirements, timescales, resources or budgets. So to continue my above argument, that's why we need a more scientific approach to software development, so we can quantify the trade-offs that have to be made in a real-life project and use them to argue our corner with management.
|
|
|
|
|
First thing, a talented development team will include talented requirements gathering and project management. A development team is most definitely NOT just developers...you need a well-rounded set of skills spread amongst the team, with specific skill sets concentrated in one or two people at a time. If your development team consists solely of developers...then thats your first problem.
As for a more scientific approach to software development, there has actually been a VERY scientific approach for many decaedes, which many people call the waterfall methodology (there are a few well-specified varieties that many companies are very succesful with). When you plan out (specify) a project, from the requirements, to hardware needs, to application architecture and component design, to specific component implementations, you HAVE a scientific approach to software development. Classic development processes from the last few decaedes can be simplified and refined to provide a more iterative approach, while still maintaining a proper level of specification in your requirements and plans. I can say with experience that agile/scrum or XP with TDD is much less "scientific" and far more "ad-hoc", and while it may be adaptable, the end result is significantly less organized, patterned, and in some respects maintainable.
While unit tests themselves can provide a "specification" of sorts, its a weak one that only specifies a fine-grained unit. You completely loose the benefit of higher-level architectural specification unless you put time into developing that in addition to your unit tests. An architectural specification can be maintained as time allowes without loosing confidence in your application...however, unit tests are more code surface that must be maintained and debugged just like all the code it tests. A buggy unit test can be just as bad, if not worse, than buggy code.
Well architected software has a significantly greater chance of working when deployed, even in the abscence of unit tests. My confidence level us probably not always 90%, but usually well above 50%. TDD is a nice concept, but it requires a LOT of factors to fall into place an sync, not just within a development team, but between development and management, within management itself, and between a company and its customers. It is, as I mentioned before, a lot more work too...additional code to write, debug, and maintain.
A better development methodology for writing stable software that you can be significantly confident in, in my humble opinion, is DbC, or Design-by-Contract. Ultimately, software development is all about contracts between providers and consumers of some kind of service (and thats true at many different levels...method-to-method, object-to-object, or subsystem-to-subsystem). In languages such as Eiffel or Spec#, you have the ability to specify contract requirements directly into your code, ensuring that its used in the proper way, with barely 5% of the code required to write enough unit tests to provide useful value. The sad thing is that DbC is currently only truely available through Eiffel or Spec#...and Spec# is pseudo-beta. :\ Some alternatives exist that provide some of the most useful features of DbC, but the whole implementation as it exists in Eiffel is really neccesary to recieve full benefit.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Badger | [badger,badger,badger,badger...]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/badger.gif)
