|
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.
|
|
|
|
|
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?
|
|
|
|
|