Programmers, Do you think it's effective to work in a big group

[chronodekar]

Originally posted by: Crusty
If one person can't follow the rules what makes you think two people will?

The idea is that the 2 of them will understand the code. If more than 1 person understands the submitted code, there is a higher chance that it will be more readable than if it were by just 1 guy/gal.

(posted in a half-dazed state, might issue corrections later... ZZzzz... sorry in advance...)


Edit: (am a bit more sober now) I know an uphill battle when I see it guys. I'm laying down my arms on this one.

-sigh-

Seems that I have a one-man view point here.

 

[Markbnj]

Originally posted by: chronodekar

Originally posted by: Crusty
If one person can't follow the rules what makes you think two people will?

The idea is that the 2 of them will understand the code. If more than 1 person understands the submitted code, there is a higher chance that it will be more readable than if it were by just 1 guy/gal.

(posted in a half-dazed state, might issue corrections later... ZZzzz... sorry in advance...)


Edit: (am a bit more sober now) I know an uphill battle when I see it guys. I'm laying down my arms on this one.

-sigh-

Seems that I have a one-man view point here.

Oh not at all, really. A lot of people agree with you. I guess for me it just seems like a management attempt to formalize something that has always existed, and works well on any close-knit team that does participatory analysis and regular code reviews. I'll be the first to admit I have a somewhat cynical and jaded view. I think there are almost no businesses outside the computer industry that really understand what they are doing when they develop their own software.

I visited a huge retailer years ago that was opening like a hundred new stores a year. I expressed my amazement at an undertaking like that, and my host told me about how standardized the designs and processes were. The whole thing was a machine. That's production, in Jack Reeves' definition, where the design is fully specified and can be repeatedly executed to create output.

Business management tries to control programming as a production process. That's where we get metrics like lines of code, defects per kloc, function points, etc. Each one of these things that has come along has been an attempt by the layer of management that is responsible for what we do to understand what we do, and why it so often is hard to predict how well we will do.

Now imagine trying to apply the same management techniques to any other engineering or scientific research discipline. How many designs should a good automotive designer produce? How many molecules should a good biologist examine and reject in a certain time? Should architects designing a bridge always work together in a large room with their manager?

Moreover, how much molecular biology, automotive design, or architecture gets off-shored to the lowest bidder?

These are high-value, creative design processes. They are not production. That comes later. Programming is also a creative design process. For very fundamental reasons nothing we do is likely to ever change that. Our production comes later, too. It's called compilation, and it's both inconsequential and free. That's the problem in a nutshell. In most other businesses the ultimate costs of production dwarf the costs of design. System development is all design, and little production. It's entirely front-end, which means that the whole process from front to back is as risky and uncertain and dependent on individual inspiration and insight as any of the professions I mentioned above.

Most businesses, if they really understood system development, would not develop systems. And most of them shouldn't. Engaging in system development is no different from firing up any other expensive R&D process: all cost and no joy for years to come. You have to have a powerful long-term vision of how the software will improve your business to risk dollars on it. I think if more businesses really understood what they were getting into there would be less offshore development, more independent ISVs, a bigger support and services sector, and a crapload more respect for the people who, after all, are the only people on the planet who can do what we do.

 

[Cogman]

Originally posted by: Markbnj

Originally posted by: chronodekar

Originally posted by: Crusty
If one person can't follow the rules what makes you think two people will?

The idea is that the 2 of them will understand the code. If more than 1 person understands the submitted code, there is a higher chance that it will be more readable than if it were by just 1 guy/gal.

(posted in a half-dazed state, might issue corrections later... ZZzzz... sorry in advance...)


Edit: (am a bit more sober now) I know an uphill battle when I see it guys. I'm laying down my arms on this one.

-sigh-

Seems that I have a one-man view point here.

Oh not at all, really. A lot of people agree with you. I guess for me it just seems like a management attempt to formalize something that has always existed, and works well on any close-knit team that does participatory analysis and regular code reviews. I'll be the first to admit I have a somewhat cynical and jaded view. I think there are almost no businesses outside the computer industry that really understand what they are doing when they develop their own software.

I visited a huge retailer years ago that was opening like a hundred new stores a year. I expressed my amazement at an undertaking like that, and my host told me about how standardized the designs and processes were. The whole thing was a machine. That's production, in Jack Reeves' definition, where the design is fully specified and can be repeatedly executed to create output.

Business management tries to control programming as a production process. That's where we get metrics like lines of code, defects per kloc, function points, etc. Each one of these things that has come along has been an attempt by the layer of management that is responsible for what we do to understand what we do, and why it so often is hard to predict how well we will do.

Now imagine trying to apply the same management techniques to any other engineering or scientific research discipline. How many designs should a good automotive designer produce? How many molecules should a good biologist examine and reject in a certain time? Should architects designing a bridge always work together in a large room with their manager?

Moreover, how much molecular biology, automotive design, or architecture gets off-shored to the lowest bidder?

These are high-value, creative design processes. They are not production. That comes later. Programming is also a creative design process. For very fundamental reasons nothing we do is likely to ever change that. Our production comes later, too. It's called compilation, and it's both inconsequential and free. That's the problem in a nutshell. In most other businesses the ultimate costs of production dwarf the costs of design. System development is all design, and little production. It's entirely front-end, which means that the whole process from front to back is as risky and uncertain and dependent on individual inspiration and insight as any of the professions I mentioned above.

Most businesses, if they really understood system development, would not develop systems. And most of them shouldn't. Engaging in system development is no different from firing up any other expensive R&D process: all cost and no joy for years to come. You have to have a powerful long-term vision of how the software will improve your business to risk dollars on it. I think if more businesses really understood what they were getting into there would be less offshore development, more independent ISVs, a bigger support and services sector, and a crapload more respect for the people who, after all, are the only people on the planet who can do what we do.

The problem comes in where as programmers you would love for management to have a good understanding of programing. As management you don't want to have to know anything about it, you just want to be able to say "Hey, how far along are we and when will it be done". Its ironic because we are being measured by quantity of code produced (almost like measuring a factory by the number of cars it can produces) when really, the quality of code should be the most important metric. If there is some quantity that management should be concerned about it is production of the final software (which goes fast enough that its a moot point, unless you have a killer app on your hands).

But, deadlines can be good in some cases. If a programmer has a target to shoot for they often work just a little bit harder, they just need to be set in a realistic manner and based on things like "module A should be completed by Dec 1. ect.." not, "We need this program to be at 40% by friday"

 

[LumbergTech]

I think it highly depends on the people involved whether team programming is good. At times, it can be quite good. If the two people are equally skilled, but with somewhat different skill sets, it can literally double the information you have access to

 

[Markbnj]

"Hey, how far along are we and when will it be done"

And that's the problem. It's unrealistic to expect business not to care at all how long something will take, but it is equally unrealistic to expect anyone involved with a large software project to know the answer to any degree of certainty.

The philosophical divide is between two views. The management view is: we've specified this thing and now we just have to chew through the implementation. The real view is: we have a pretty good idea what they want, now we have to design a solution.

In the first view programmers are just monkeys sitting between super smart business architects and the compiler.

In the second they are the designers of the system and translators of the user's intentions into code.

Very different outlooks. If you hold to the first one, then programmers are replaceable components, and you can freely shop their jobs out to whatever global bidder will work for $10 less a day. If you hold to the second then you know how foolish that idea is.

 

[hans007]

Originally posted by: KB
9 people in one room? You can't get anything done like that. 4 at most and even then they shouldn't all be working on the same thing.

It sounds to me the project manager is concerned about his programming skills, but wants to make sure he can still program in case he loses his job as a manager. I would be pretty miserable myself in that situation.

I can barely stand having a cubicle myself.

Not all programmers can work best in the same environment.

I would haveto say that almost everyone i've known who has done the "open office" lots of people in one room thing hates it.

That may work for like accountants or something or Sales people, but it destroys your ability to focus.

I also personally hate pair programming. In my experience it leads to one person who is obviously much more of a badass than the other person dragging a piece of dead weight around.


Also to the person who said that developers do unit tests, yes that is true, but some organizations (usually ones with more money) hire white box testers who do nothing but analyze code and write test harnesses and unit tests. A lot of companies have started to call this "software developer in test" or "software developer in qa" or something like that. I used to work at the big security firm that everyone hates, and that was basically my job, just look over code and write tests. If you have a lot of hot shot developers who are spending their time say fixing bugs, its worthwhile to have maybe some more junior guys do the tests and such as to not waste the hot shot developer's time. It also helps you train new guys to turn into developers i suppose.

 

[chronodekar]

Originally posted by: Markbnj

"Hey, how far along are we and when will it be done"

The philosophical divide is between two views. The management view is: we've specified this thing and now we just have to chew through the implementation. The real view is: we have a pretty good idea what they want, now we have to design a solution.

I agree with all this. But I feel that it's incomplete. No matter which viewpoint you take, I haven't come across a standard definition (if it exists) on HOW to measure software quality. As a programmer, I think that if the end-user is satisfied/happy then, I've made a good quality product. But, HOW do I determine that DURING the coding? And NOT 4 months after the project is over? (The feedback is valuable, yes, but I'm addressing another concern here)

There are some managements (& coders, sadly) that view number of lines of code as a measure of productivity. ... Something, I strongly disagree with.

What I have generally found, is that if the amount of rework required on a piece of code is minimal, then that code is a prime candidate for well written software.

But even with that definition, we return to the same problem we started with. How can you measure the quality of the software you've written so far?

Going a bit off-topic here, but in the end, I think programmers end up in the same situation that doctors are in. The really good one is someone who forces you to take a vaccine, and you never get sick. But what everyone considers/calls a great doctor is one who patches you up AFTER you get sick. (At least, they get the blame too if something horrible happens)

So.. where does that leave us? If you want to be called a great programmer by everyone, you need to know how to convert broken code to working code. If you want to be true to yourself and write quality software, you have to be ready to be taken for granted and forgotten by most. (let's ignore the exceptional cases)

-sigh-

The world we live in. 😕

 

[Markbnj]

I agree, and see that as an aspect of the same problem. If you accept that the act of programming is design, then you have to view bug fixes and changes as reworking the design. Why does a design have to be reworked? Because the results of production are unacceptable. In industrial production scenarios the costs of production failures is so high that extraordinary effort is put into getting the design right. There is a continuum of risk vs. time extending from, say, a toaster on one end, to a 747 on the other. In terms of functional complexity a moderately large line of business application falls somewhere in the upper half of that range, imo. Somewhere around "Chevy Tahoe."

It takes three to five years to design a new vehicle model, test the design, refine it, tool up, and get it into production. The effort is exhaustive on every level because the costs of farking it up are massive.

Compare that to the average system development project where you're lucky if you can get the users' attention for thirty minutes without them nodding off or hitting their Blackberries. That's partly because the costs of production are so low, and partly because the risks of error are very low too. There are some sectors where the latter is reversed, and the risk of error is huge. I've never worked a milspec project or an air traffic control system, that sort of thing, but I have friends who have, and the whole process is much more rigorous. Those users might ignore their email and listen if they bore personal liability for an aircraft accident.

Thing is, I actually don't think we have a general problem with not knowing how to write good software. There are companies and teams writing great software all over the place. It takes a clear vision of what you want, a talented group, and iterations of improvement to get it all right and create something great.

I think the problem is with Corporate IT empires accumulating responsibilities they can't handle, and business management diving into projects they don't understand. When the inevitable failures occur the whole industry is blamed for not understanding its craft. If business people understood each software system as an incredibly complex, custom built piece of machinery they would treat it more seriously, or not spend money on it in the first place. But it's just software, so what the hell, we can always change it.

 

[chronodekar]

Originally posted by: Markbnj
But it's just software, so what the hell, we can always change it.

Sad, but true Mark. Sad,But True.

If only we could change that attitude. Or figure out a way of knowing where it is necessary to apply it and where it is not.

 

[hans007]

Originally posted by: chronodekar

Originally posted by: Markbnj

"Hey, how far along are we and when will it be done"

The philosophical divide is between two views. The management view is: we've specified this thing and now we just have to chew through the implementation. The real view is: we have a pretty good idea what they want, now we have to design a solution.

I agree with all this. But I feel that it's incomplete. No matter which viewpoint you take, I haven't come across a standard definition (if it exists) on HOW to measure software quality. As a programmer, I think that if the end-user is satisfied/happy then, I've made a good quality product. But, HOW do I determine that DURING the coding? And NOT 4 months after the project is over? (The feedback is valuable, yes, but I'm addressing another concern here)

There are some managements (& coders, sadly) that view number of lines of code as a measure of productivity. ... Something, I strongly disagree with.

What I have generally found, is that if the amount of rework required on a piece of code is minimal, then that code is a prime candidate for well written software.

But even with that definition, we return to the same problem we started with. How can you measure the quality of the software you've written so far?

Going a bit off-topic here, but in the end, I think programmers end up in the same situation that doctors are in. The really good one is someone who forces you to take a vaccine, and you never get sick. But what everyone considers/calls a great doctor is one who patches you up AFTER you get sick. (At least, they get the blame too if something horrible happens)

So.. where does that leave us? If you want to be called a great programmer by everyone, you need to know how to convert broken code to working code. If you want to be true to yourself and write quality software, you have to be ready to be taken for granted and forgotten by most. (let's ignore the exceptional cases)

-sigh-

The world we live in. 😕

I worked a a major software company where for the consumer product division the idiotic management would actually put up charts by employee as to the number of bugs each QA person found, and the number each developer fixed.

I know this because... i wrote the intranet sites that tracked it haha. That said, it did not matter how obvious the bug was (typo, vs.. insane thread deadlock or something) and it didnt matter which ones you fixed. these would be put on a wall witha colorful chart and actaully used to award like one time bonus awards.

that said, devs AND QA people hated this (i worked in qa at the time). This company is well.. the largest security software company in the world. I would imagine similar ridiculousness happens at every large company with managers who were never developers or testers as the NEXT company I worked at did similar things, except they even clocked the number of hours each person spent fixing a bug (so i suppose these metrics are not quite as awful).

I work at a small ISV now as a developer and thank god they don't do that there. Seriously, 98% of how to be a manager at a large software firm, is how much brown you can get on your nose.

 

[Cogman]

Originally posted by: hans007
I worked a a major software company where for the consumer product division the idiotic management would actually put up charts by employee as to the number of bugs each QA person found, and the number each developer fixed.

I know this because... i wrote the intranet sites that tracked it haha. That said, it did not matter how obvious the bug was (typo, vs.. insane thread deadlock or something) and it didnt matter which ones you fixed. these would be put on a wall witha colorful chart and actaully used to award like one time bonus awards.

that said, devs AND QA people hated this (i worked in qa at the time). This company is well.. the largest security software company in the world. I would imagine similar ridiculousness happens at every large company with managers who were never developers or testers as the NEXT company I worked at did similar things, except they even clocked the number of hours each person spent fixing a bug (so i suppose these metrics are not quite as awful).

I work at a small ISV now as a developer and thank god they don't do that there. Seriously, 98% of how to be a manager at a large software firm, is how much brown you can get on your nose.

🙁 that's terrible. I would totally abuse the system just to show how ridiculous it is. (IE, find 100 typos, inconsistent standards, ect). Even the whole "clock number of hours spend fixing a bug" is a bad idea, could you imagine. "Well, ted fixed his bug in 30mins, it took you 2 hours to fix yours, whats wrong with you?"

 

[imported_Dhaval00]

Some of the topics discussed here so much reflect Brooks' findings that he documented 35 years ago. It's just horrendous to come across individuals who don't know the ABC's of software engineering. I think every individual who has anything to do with creating a piece of software must be forced to read Fred Brooks' The Mythical Man-Month. Sure, management is the devil when addressing failed projects. But at the same time, engineers must also understand the needs of management - too often I see people, engineers in specific, whine about management when it is a collective failure at the team level. And who gets the boot in the end? Most of the times, project managers.

Time and again, people fail in software engineering because they become stagnated with their ideas and they're not flexible enough to travel back in time to learn from others' bad experiences (everyone can have a vision for the future). You'll always need nine months (on average) to create a baby - you can't bring nine women to the table and expect them to deliver a baby within one month. As Brooks' Law (for the software evangelists amongst us) suggests, there is No Silver Bullet in software engineering. And that statement stands true for both management and engineers (be it software or test).

At the core, most engineers will quit and job hop because it is too easy. Very few of us actually want to do something about the shortcomings. And yes, I'd probably choose the easy way out, too. In the end, the higher level observation is that people who have been in the trenches, will often make good to great managers.

The real issue is that programmers are half as good as they were twenty years ago. In ten years they will be 1/3 as good and you'll need three.

I hope you were being sarcastic, Mark. Because if not, I whole-heatedly disagree with that statement.

 

[chronodekar]

Hmmmm... the wiki entry for that book looks interesting. I think I'll hunt it down. Also, it looks like a good candidate for a book review.

Don't worry, I'm sure Mark was being sarcastic. If I felt any other way, I would have pounced on it. 😉

But, since you brought it up, it does look like a trend, right? 10 years ago (before my time) it was widely agreed that a single programmer is enough to make good software. Now, pair programming is gaining traction in some circles.

In another 10 years, who know? It may as well be 3. :roll:

 

[imported_Dhaval00]

Originally posted by: chronodekar
10 years ago (before my time) it was widely agreed that a single programmer is enough to make good software. Now, pair programming is gaining traction in some circles.

In another 10 years, who know? It may as well be 3. :roll:

I tend to think the opposite - since we now have access to higher level languages, we require programmers to be less alert and less accurate. These are the wonder years of lazy programming. We have too many tools, IDEs, and ideas at our disposal. Ten years ago maybe you'd have needed three pairs of eyes to dealloc that object in native C/C++. Today's garbage collectors don't need any tending to.

What is my take on pair-programming? I think it depends on the context: if a newbie is being mentored, pair-programming makes perfect sense; if two skilled developers have a go at it, they better be trying to find some multi-threading bugs.

 

[Markbnj]

I hope you were being sarcastic, Mark. Because if not, I whole-heatedly disagree with that statement.

Yeah, I was being sarcastic, but there is some truth to that statement. Programming is a much larger business than it was twenty years ago. There are whole swathes of the globe involved now that basically weren't doing any development back then, or very little. In general I think the level of expertise has gone down. You don't see it in a place like this, but try answering questions on one of Microsoft's forums for a couple of hours. It's mostly stuff like this:

"ok so guys im tryin to put a control in teh grid, but teh grid keeps saying an exception can u help plz?"

It's just democratization I guess, and the prevalence of web applications, which are the Yugos of system development.

What is my take on pair-programming? I think it depends on the context: if a newbie is being mentored, pair-programming makes perfect sense; if two skilled developers have a go at it, they better be trying to find some multi-threading bugs.

Haha. Exactly.

Oh, and Mythical Man Month, of course. It was just about required reading for many years. Gerry Weinberg's stuff is pretty good too. It all falls into the category of "observations on the failings of humanity" as far as I can see. The people who organize and lead us are never as good as they should be, and we're never as good as we think we are.

But I really feel programming is in a unique rut these days. Way, way undervalued and strategically misunderstood.

 

[chronodekar]

Originally posted by: Dhaval00
Today's garbage collectors don't need any tending to.

Wouldn't that depend on whom you are talking to? 5 years ago, the entry level was considered respectable in an educational institute. With the bar so low today, I guess it's a natural consequence that the IQ of an average programmer has fallen.

Just because the tools have gotten easier to use, that does not mean that we don't need quality programmers. I think that it just lets them produce much more efficient code than before.

To quote from the MyticalManMonth,

the $20,000/year programmer may well be 10 times as productive as the $10,000/year one

Since our tools are much better now, I'd say that the level of productivity is much more than a mere 10.

In the long run, skilled programmers are the better investment. 🙂





PS- I just started chapter 3 of the book now.

 

[imported_Dhaval00]

Yea, but, just because the tools have made programmers' lives easier doesn't mean that their IQ has gone down. In fact, I'll come across quite a few 'senior' developers who hardly know how to make the RESTful call to the back-end, for example. Does that mean I, being the junior developer and who knows RESTful services, am 10 times more productive? It goes back to that state of stagnation that I mentioned earlier.

The bar is so low because the programming field is like an open market vis-a-vis economics. You make a product, segment the market, and start selling the product. You make shit loads of money and become fat and lazy. Since there are profits to be reaped, other competitors (programmers) will enter the same market and will want some of those profits. There are no barriers to entry and there is no government regulation (thank god!). Java and C# have made entering the 'market' quite easy - most people pursue the field because it is easy money not because they adore it. At some point, the market will saturate at the entry-level - if you want to be in business, you better find your niche! From what I know and from what I have observed, most people are resistant to learning - those who are not are at the top of their game. Of course, there will be exceptions.

IMO, there are ample of quality programmers out there. You just need to ask the right questions before letting someone in. For example, most programmers will get interviewed by other programmers. This creates a closed environment and people have the complete tendency to be locked in a state of "group-think." Should you hire someone because he or she answered all the questions the lead developer asked? I bet you, a month later, I wouldn't be surprised if the new guy and the lead developer are having a go at each other. This same analogy can be extended to any other interview in general. How many places do you know of that actually allow subordinates (people below the interviewee's position) to conduct an interview? It is the incentive structure beneath which is in an abysmal state. We don't get rewarded for preventing the fire, but for putting out the fire 🙂.

As a side note, problem with us programmers is that we have huge egos (even I do). I have been trying to check my ego out at the door before I enter my workplace - hell, sometimes I'll also try and leave it there overnight. We have all made great statements about the OP's state of work. But we must also take a peek at the other side of the spectrum - what lead to that state (where nine people are stacked into a single room)? That's where the whole notion of 'people skills' come in. From the discussion above, it seems the manager as well as the OP have shunned all forms of sane communication because if they hadn't, they'd be more than comfortable talking about this situation.

As good as the Mythical Man-Month is, there are some quotes/ideas that I'll be wary of (just a few). Again, the book's primary subject is software project management, so I'd concentrate on that piece.