G
Gerhard Fiedler
Ian said:
So you agree that Microsoft must be producing good code? Just
checking...
Gerhard
So you agree that Microsoft must be producing good code? Just
checking...
Gerhard
A
Abhishek Padmanabh
Similar to daily plans are the stand-up meetings. Here are some
details on it - http://www.martinfowler.com/articles/itsNotJustStandingUp.html
It won't make much sense if you have a team of 2 including yourself
but you always have the options to tailor it to your needs. But such
catch-ups surely help provided you have the right implementation such
that it doesn't go much off-track and it isn't taking too much time.
Some of the pitfalls are available on the link above like: story-
telling.
WBS (http://en.wikipedia.org/wiki/Work_breakdown_structure) might
provide you some control too. It will probably ensure that the team
knows what a particular delivery unit is and would help measure the
progress better with clarity both for you and your team.
I must say that I have not been in a management/lead role myself but I
have been a relatively new practitioner of the above 2 and they have
somewhat helped in terms of greater clarity for the team, measuring
progress, sharing knowledge among the team. Important is that the team
including the lead/manager has the belief/buy-in, where mostly the
challenge lies.
R
Rafael Anschau
Here´s my take on it:
In school you learn that things have to be almost perfect
to get a good grade, even if takes two months to do it.
Then you move to the busyness world where things have to be
ready for yesterday, and as long as they work, it doesn´t mater
if they are inefficient, patchy, bloated and ugly. Bosses(clients,
internal or external)
prefer a bad working code today, than a perfect one in two months.
This often takes time to be accepted by some(it surely took for me,
and I don´t
fully yet accept that yet, but it´s slowly sinking in).
Another problem maybe in the communication:
I think the best way is to communicate in terms of problem/time/
suggestions/restrictions. 'I have
this problem that I need solved for a week. My suggestion is that you
use this, this
and this but if you can think up something, better go ahead. Oh there
´s also this
and this restriction"
But by all, means don´t behave like "I need a facade pattern"(who
knows he may think of something better!why would that ever be a
restriction ?) using this this this and this. And variables and
commentaries should be in this style."
(Go ahead pawn!)
Developers like to use their brains, and not just be the hands and
legs of someone
else´s brains.
Someone sayed: "Trying to manage programmers is like trying to herd
cats"
Have you ever tried to use Scrumm ? I think it´s a quality methodology
that suits your problem very well.
Good luck.
Rafael
In school you learn that things have to be almost perfect
to get a good grade, even if takes two months to do it.
Then you move to the busyness world where things have to be
ready for yesterday, and as long as they work, it doesn´t mater
if they are inefficient, patchy, bloated and ugly. Bosses(clients,
internal or external)
prefer a bad working code today, than a perfect one in two months.
This often takes time to be accepted by some(it surely took for me,
and I don´t
fully yet accept that yet, but it´s slowly sinking in).
Another problem maybe in the communication:
I think the best way is to communicate in terms of problem/time/
suggestions/restrictions. 'I have
this problem that I need solved for a week. My suggestion is that you
use this, this
and this but if you can think up something, better go ahead. Oh there
´s also this
and this restriction"
But by all, means don´t behave like "I need a facade pattern"(who
knows he may think of something better!why would that ever be a
restriction ?) using this this this and this. And variables and
commentaries should be in this style."
(Go ahead pawn!)
Developers like to use their brains, and not just be the hands and
legs of someone
else´s brains.
Someone sayed: "Trying to manage programmers is like trying to herd
cats"
Have you ever tried to use Scrumm ? I think it´s a quality methodology
that suits your problem very well.
Good luck.
Rafael
P
Pascal J. Bourguignon
Ian Collins said:
Indeed, when customer satisfaction and bottom line is the target, bug
counts are irrelevant. Or any _other_ aspect of goodness.
That's why you're not as rich as Bill Gates.
There's no bug that can overcome a good marketting campain (which can
minimally be just a nice splash screen) to make users happy.
Asking the credit card number of your customers first thing on the hot
line is also a good way to avoid dealing with bugs.
N
Noah Roberts
Abhishek said:
We did stand ups here and they were a total waste of time for us. We
got the same stuff I got when just asking, "How are things going?"
People respond with, "fine," and in stand-ups that would be, "I'm doing
backlog item XXX and everything's going great." Everyone knows you're
doing backlog item XXX and the later is not informative.
N
Noah Roberts
Ian said:
Well, it sounds to me like you have "good" design in there (measured by
the ease with which you fix bugs or perform follow up work) so I'd be
happy with that definition. I think LOC is a really silly metric. I do
loosely have a max LOC per function requirement but it's very loose.
Surely. I still think it's more communicative to use the direct terms
though. "I write software that my customers are happy with," is more
informative and correct--and hard to argue with--than, "I write good
software."
J
James Kanze
I wasn't going to respond any further here, since the argument
is really "Everyone I've ever worked with is incompetent" (from
Andrew) and "I'm just being argumentive if I dispute this" (from
Noah). As it happens, most of the people I've worked with, with
very, very few exceptions, are good programmers, the insults
thrown out gratuously by Andrew not withstanding. (And until
Noah understands this basic principle, he's not going to be able
to effectively lead a team. Leadership starts with respect for
your subordonnates.)
As for the idea that no good programmer would work at a bank:
http://bartelby.net/17/1/31.html. In fact, I've over thirty
five years of professional experience, in many different
domains: OS, compilers, embedded systems, telecoms and banks,
and there's no significant difference in the level competence
depending on the domain. (There is a difference in the fields
of competence---you'll find a lot more experts in numeric
programming working in investment banks than on embedded
systems.)
As for the +100 factor: superman only exists in comic books;
human beings just don't vary that much in their capacities.
As for the statement "one person, working alone, cannot write a
good program", it's obviously a simplification, and a bit of
hyperbole, since it doesn't mean much without a definition of
good, when applied to a program, and "working alone", for that
matter---witness the discussion about TeX. (I wouldn't consider
anyone writing reviewed works in a University context "working
alone". But the collaboration is obviously of a different
nature than that usual in enterprise, and I can understand a
difference of opinion concerning that definition.)
[...]
Certainly. It's a necessary condition. It's not a sufficient
one. (Good software doesn't crash. Regardless of how good it
is in other aspects.)
It just happens to be the easiest one to measure. And one that
can't be achieved by a person working in isolation, at least as
far as I can tell. (For non-trivial software, of course.)
[...]
I supposed that my data was well known to most practionners,
since it has been widely published. If not,
http://www.sei.cmu.edu/ is a good place to start.
The majority of software teams probably can't. It takes at
least an SEI level 3, and I think (without looking it up, so
don't bet on it) that that's less than 10% of the organization
the SEI has measured. It takes a pretty good process to get to
that level; only one of the places I've worked has achieved it.
But it's certainly a possibility, and at least one place has
documented significantly better. My experience (and this is
very subjective) is that anything you do bringing you closer to
the 1 error per KLOC tends to reduce costs in the long run
("quality is free"); I can't really say for sure, but
intuitively, I suspect that going beyond that will quickly
become very expensive. (The organisms which do significantly
better generally have to, regardless of price.)
As for why a single person can't do this well... Well, I've
known a lot of really good programmers---some of the best, in
fact, and none come anywhere close. And given that some of
these are at the upper limits of competence, and given the
limits in variance in human performance, it seems like a very
reasonable assumption. Do you know, or have you even heard of,
anyone who even claims anything close to this. (I know my upper
limit is about 1 line per 10 KLOC, and I don't always perform at
that level.)
Concern for errors does mean that you have to evaluate risks.
So does most other things. Radical experimentation belongs in
the University, not in industry. And I've never heard of a
client who pays just for something to be "new"---they want
working solutions to real problems. (And from experience---the
first program to exploit a new idea is never "good". There's a
reason it's called the "bleeding edge".)
It depends on how many people are in the team, and how complex
the problem domain is.
Anything that has to be fixed.
Or even in the log file output, or the documentation. Anything
that causes you to have to change something in the deliverables
after delivery. (From the programmers point of view, delivery
is delivery to the integration team, at least on large
projects.)
It varies, but in the places I've worked, four to six people in
each group seems to be about optimal. The larger the project,
the more groups you need. Or maybe I should say, can use;
there's an upper limit to the number of groups that can be used
effectively, which varies according to the size and complexity
of the project.
One person doesn't develop "error free LOC". And it's very
difficult to discuss time in the abstract, because it varies so
much. In cases where I have a rigid, fixed specification of
exactly what the program is to do, and it involves a field in
which I have expertise, I'm capable of producing about 40 KLOC
in a man year, with about 1 error per 10 KLOC. But those
conditions are very exceptional, almost never met. And that's
working alone---the results are, I think, better than most could
do, but they're still not what I would consider "good". For
that, I need help---code reviews, etc. (At the other extreme,
if the customer has no real idea what he wants, or you're
working on something so radically new that you need to develope
completely new algorithms, then you can easily spend a man-year
producing no lines of code.)
The important thing, of course, is to be able to measure what
you're doing, so that you can determine whether any change you
make is an improvement or not.
As I said, you might start with the documentation at the SEI
site quoted above. Particularly
http://www.sei.cmu.edu/publications/key-publications.html and
the link to process improvement. Most of what they suggest has
been around for awhile, and has proven its value.
I
Ian Collins
James said:
James, have you read
"CMMI or Agile: Why Not Embrace Both!"?
http://www.sei.cmu.edu/pub/documents/08.reports/08tn003.pdf
A
Andrew Tomazos
That is a childish misrepresentation of what I said. If you don't
understand where the statement "a good programmer can be 100x
productive as an average one" comes from than my guess is you haven't
worked with any *really* good programmers.
Surely you don't claim to have worked with every programmer on Earth?
Given that you have not, why isn't it possible that some of the
programmers you have not worked with are significantly better than the
best programmer you have worked with? You must concede it as, at a
minimum, logically possible.
Given that it is possible, why do you so fervently deny it? I would
quite happily accept you saying that you have not seen the phenomenon
- but you are claiming that it doesn't exist because you haven't seen
it. When someone digs a trench like this they usually have a vested
interest in their position being true:
The fact is a lot of engineering process designers and project
managers would love it if programmers were homogeneous interchangeable
parts. It would make a managers job so much easier that some even try
to bury their head in the sand and pretend that this is the case. X
programmers produce Y lines of code with Z errors.
Unfortunatelyit just doesn't gel with reality.
Programmers vary greatly in their level of productivity (yes as much
as 100x). I repeat: I have seen this firsthand, I have heard
firsthand account, it has been written about in books.
-Andrew.
B
Balog Pal
"Andrew Tomazos" <[email protected]>
I'm quite sure James worked with some of those.
What I seriously doubt from reading many his posts, that he worked with bad
ones. And mor importantly with many average ones. And if you cut the
first 80% of measuring data, certainly different figures will emerge.
Being able to find the good places to work, and restrict to only those is a
good thing -- but not too widespread.
I'm quite sure James worked with some of those.
What I seriously doubt from reading many his posts, that he worked with bad
ones. And mor importantly with many average ones. And if you cut the
first 80% of measuring data, certainly different figures will emerge.
Being able to find the good places to work, and restrict to only those is a
good thing -- but not too widespread.
N
Noah Roberts
Andrew said:
That's really just silly.
I see arguments just like this quite often when people try to get me to
believe in supernatural boogymen or start praying to rocks. I'm not
going to speak for Kanze of course but I see a very clear difference
between "logically possible" and "realistic". Logic isn't actually that
great for telling us about the real world.
You can logically prove all kinds of ridiculous ideas with false or
questionable premises; mix a contradiction in and anything is provable.
You can also invent all kinds of insane ideas that are completely
impossible to logically disprove. People who base everything on logic
are not going to get anywhere if they don't check their logic with
reality once in a while.
So, for example, if someone were to come to me and say they have a rock
that can think I'd utterly dismiss the idea entirely. I wouldn't even
entertain it as possible. Can I logically prove that some given rock is
not sentient? No, never. Do I need to before I laugh at the person or
kindly let them know they might need mental help? No.
I would
Actually, Kanze has put a lot more out there than just that he's never
seen one. You should go back and read what he's said if that's all you
think he's basing his opinion on. I'm not saying he's right or that I
agree with him but this really is an unfair statement about his position.
The fact is a lot of engineering process designers and project
managers would love it if programmers were homogeneous interchangeable
parts. It would make a managers job so much easier that some even try
to bury their head in the sand and pretend that this is the case. X
programmers produce Y lines of code with Z errors.
it just doesn't gel with reality.
And as far as I can tell Kanze hasn't said otherwise here either. There
are definitely really good developers and "free electrons" as Rands puts
it in his book, but there's no such thing as a super-programmer.
N
Noah Roberts
James said:
I really don't know where you get off on these accusations but I guess I
can't expect any better from you. It seems clear to me that you're
perfectly happy playing the insult game until you run into someone
that's just as happy to play and maybe a bit better at it. I would
kindly ask that you actually quote me insulting people or showing
disrespect to "subordonnates" but actually backing up your accusations
has not been your strong suit. This is like the times you insisted I
write crap code when you'd never even seen one line...more shit for the
pile, Kanze.
Keep it. In the words of Overkill:
YOU! Got a lot to learn.
Your head's up your ass!
YOU! Got a lot to learn.
You got no class.
No class.
D
Dilip
What is with this newsgroup? People seem to be waiting for an
opportunity to go at each other's throat. First there was Mr. Duggar
who thinks the best way to get someone to admit their mistake
(legitimate or not) is to humiliate them. The next is Mr. Roberts
who, in all this time of lurking in this newsgroup, I have never seen
agreeing with Mr. Kanze on anything (not that its a bad thing -- I
just wonder why this kind of language needs to be resorted to).
The thing that gets me is I have been following this newsgroup for
several years. I have learnt an enormous amount of C++ by simply
reading posts from James Kanze, Jerry Coffin, Hyman Rosen and others.
Doesn't that count for a little bit of respect or at least the fact
they, you know, might actually know what they are talking about? Like
everyone of us they are going to be wrong from time to time and I have
personally read quite a few posts where they have freely admitted it.
But even there they have been more right than wrong. Why can't we all
get along? Is it too much to maintain some civility considering, um,
we are adults?
N
Noah Roberts
Dilip said:
Well, there's no reason to reply to someone's post to say, "I agree." I
have never said Kanze is wrong 100% of the time but there have certainly
been differences.
Sometimes, sometimes not. Nobody knows everything and nobody has the
right to act like they do. Kanze tends to respond to technical
differences with non-technical arguments. When someone regularly gets
into arguments about who's worked with "good programmers" with many
different opponents there's probably something to look at in the one
consistent feature of those arguments. As Despair Inc. says, "The only
consistent thing in all your broken relationships is you."
Like
I think I have a right to respond to baseless accusations. Having been
on the receiving end of such from Kanze many, many times I also tend to
have a very different view that you do. Try disagreeing with him
sometime and then lecture me. Thanks anyway for the feedback but I
don't agree with your assessment.
R
Rafael Anschau
Book suggestion: 201 principles in Software development. The chapter
on management may suit you well.
Rafael
on management may suit you well.
Rafael
I
Ian Collins
Andrew said:
Like James, I don't believe one human can be two orders of magnitude
better at a chosen occupation than another. The other simply wouldn't
graduate. If he or she did and managed to con their way into a job,
they wouldn't stay employed for long
Care to cite the references?
B
Balog Pal
Ian Collins said:
I can't really get this part on magnitudes.
I have seen several (rather say many) programmers, and even more managers,
whose contribution to the project's progress and success is negative.
Whoever think my experience is unique, please go to thedailywtf.com, to find
a zillion of reports.
If you just take a plain vanilla honest programmer, who just does the job
say processing a backlog item every 2 weeks for good -- how his performance
measures up against that of the draggers-down?
I
Ian Collins
Balog said:
That's a fair point but I was using the "typical" programmer as a
baseline, which was fair considering the original statement was "a good
programmer can be 100x productive as an average one"
I have seen my fair share of crap programmers, I even made a good living
cleaning up after one! I've also learned how to spot them and I'm
pretty good at weeding them out in interviews.
It's way better. But that wasn't the centre of the argument, which used
average programmers as the baseline.
A
Alf P. Steinbach
* Ian Collins:
Your argument wouldn't be much different with one order of magnitude, and that's
commonly observed. So where does the argument go wrong? It's simply that the
argument assumes that the requirements for graduating and holding a job, in a
technical profession, have to do with productivity and/or quality, a sort of
monotonically increasing function, whereas in reality there can be little direct
connection between technical ability and success, and whereas success can have
more to do with conformance and social issues. In fact, a recent career guide in
Norwegian "Dagens Næringsliv", a leading economics newspaper in Norway,
cautioned strongly against doing too well while at the lower rungs of the ladder
because one is then viewed as a threat both by co-workers and by one's boss, and
reader comments were uniformly positive that at last some reality was discussed.
Third google hit on "programmer productivity", citing e.g. Steve McConnell,
Randall E. Stross and [clc++m] mod (now inactive) Robert C. Martin: <url:
http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/>.
It's so common and well-known that it has its own name.
Note that this fact, the observed reality, doesn't square with your reasoning
above, and one resolution of that is as I noted above (I'm not saying that
that's the only explanation, but I think it's the main one).
Cheers & hth.,
- Alf
Your argument wouldn't be much different with one order of magnitude, and that's
commonly observed. So where does the argument go wrong? It's simply that the
argument assumes that the requirements for graduating and holding a job, in a
technical profession, have to do with productivity and/or quality, a sort of
monotonically increasing function, whereas in reality there can be little direct
connection between technical ability and success, and whereas success can have
more to do with conformance and social issues. In fact, a recent career guide in
Norwegian "Dagens Næringsliv", a leading economics newspaper in Norway,
cautioned strongly against doing too well while at the lower rungs of the ladder
because one is then viewed as a threat both by co-workers and by one's boss, and
reader comments were uniformly positive that at last some reality was discussed.
Third google hit on "programmer productivity", citing e.g. Steve McConnell,
Randall E. Stross and [clc++m] mod (now inactive) Robert C. Martin: <url:
http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/>.
It's so common and well-known that it has its own name.
Note that this fact, the observed reality, doesn't square with your reasoning
above, and one resolution of that is as I noted above (I'm not saying that
that's the only explanation, but I think it's the main one).
Cheers & hth.,
- Alf
N
Noah Roberts
Ian said:
Again it depends on what "better" means. How are we going to measure
it? Are we going to compare someone who's been in the field for
decades, and constantly making sure their knowledge is current, to
someone straight out of college? You would probably get close to 100x
difference in any method you chose to measure their code quality and
production.
On the other hand we might not. The best new meat knows his code.
If we compare two equally experienced developers then there's going to
be less difference, maybe. We might be comparing a senior developer
that works at Intel or some other large, well funded, and sought after
employer (someone that regularly has to compete and keep learning) to
someone that's been sitting in a corner at the state for 20 years doing
just what he needs to get by (not saying everyone at the state is a
dipshit, but there's certainly more ways for them to hide their
dipshittedness there).
I'm of the opinion that good developers do something extra on the side
to keep themselves updated. They read books, experiment with stuff they
can't experiment with at work, and they continue to bring in new, fresh
ideas. A lot of people are simply not motivated to do this but think
going to work and getting the job done is enough. I frankly don't know
what it's like in the larger companies but I see this quite a lot.
Nothing wrong with it if that's what you're about but someone who goes
the extra mile is going to be better (no matter how much of a star you
were in school) and in many cases that difference will be significant.
The other simply wouldn't
I don't think we can assume that anymore. There's many colleges out
there, and not even getting into diploma mills, that for whatever reason
seem to graduate people that still can't do the job.
If he or she did and managed to con their way into a job,
Again, it depends. If you're talking about a big company that has lots
of money and can hire the best then I'm sure you're right. In other
cases employers may tend to make do with who they can get. You run into
all sorts of varying degrees of ability in these cases. The mentoring
in can be sub-par also because people who've been there for a long time
may not have had the opportunity to be mentored either. Not that
they're bad developers or anything but if you've not had the opportunity
to learn under someone great you may never reach your potential.
So I think that though the 100x figure is a bit extreme I do believe
there can be significant differences between developers, especially when
you don't assume we're talking about some super-shop that only hires the
best and can afford to do so...and take the time to interview and
replace people when they don't pan out as expected. I think many of the
posters here may forget what the real world looks like because they work
in a more optimal environment. The real world is full of people who
somehow manage to get into positions they can't actually fulfill and
others who are just plain lazy asses.