|
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.
|
|
|
|
|
Some good points in all the posts - In my experience skipping or limiting the unit test phase is REALLY BAD software engineering practice. Have seen management do this on billion dollar plus projects with disasterous results. Talented developers arent always the best testers (Ive got to admit I hate unit testing) but a good manager will always make sure it is done to a high level.
|
|
|
|
|
Agreed - I think the main problem with maintaining other people's code is fear. Because you lack complete understanding of the code you are afraid of making major changes in case you break something. But often major changes are necessary, either to fix difficult bugs or to accomodate new requirements.
With unit tests you can remove the fear, as you have a way of confirming that any changes made have not broken existing functionality. Also the units tests are useful in teaching the maintenance programmmer how the code is intended to work, thus increasing their confidence when the time comes to make changes.
|
|
|
|
|
Good point. My experience seems to confirm what you say almost exactly. What I saw was without unit tests the code is absolutely unmaintainable. But with unit tests, is the code maintainable? That's something I would like to find out
|
|
|
|
|
The quality of the documentation on the architecture isn't really important as what is actually implemented.
I've seen more wasted effort trying to add something that should be simple into a poorly architected system. These poor architecture costs can sometime double or more the effort needed for maintenance work.
Of course, the original designer has long since declared it a success and fled the project.
Dale Thompson
|
|
|
|
|
That's what exactly I couldn't find in the options: Good design. This is the most important factor in the long run in my opinion.
Erez Nassimi
|
|
|
|
|
I was looking for this alternative as well.
Unfortunately I consider the fact that it is missing to prove a point...
Dale Thompson wrote: I've seen more wasted effort trying to add something that should be simple into a poorly architected system. These poor architecture costs can sometime double or more the effort needed for maintenance work.
Yup, been there - done that...
I have also seen how a good architecture can be beneficial to developers that doesn't really understand the underlying implementation, they just have to understand what they need to which is less error prone.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
...as in, "Developers talented at writing maintainable software". 
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?
|
|
|
|
|
No just talented developers. We're all talented right? In our own special way?
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Chris Maunder wrote: We're all talented right? In our own special way?
:josh:
My WPF Blog[ ^]
Without a strive for perfection I would be terribly bored.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
