|
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
|
|
|
|
|
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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
