When Smart Developers Generate Crappy Code 195
itwbennett writes "If you've ever worked on a team you can probably recall a time when, as a group, you produced work that was not as good as any one of you could have done on your own. Sarah Mei had this sort of sub-par teamwork experience, which she shared in her session at the O'Reilly Fluent Conference this week. Mei 'spoke about a time she worked on a team with really expert developers. Every one of them was someone whom you'd admire, who had previous written code that you and I would boast to have created. Yet, these smart people created modules that didn't talk to each other. And its quality was, to be kind, on the rotten side.' It's not an uncommon story, but why and how does it happen? The answer, says Mei, is that code quality 'is defined by its patterns of dependencies,' not all of which have equal weight. And, as it turns out, team communication is the heaviest dependency of all."
oh jeez; let's all discover agile again (Score:5, Funny)
Re:oh jeez; let's all discover agile again (Score:4, Funny)
Fix everything by having a 5 minute standup meeting for two hours every morning and then every two weeks drop everything and build a deliverable that isn't finished yet.
Re:oh jeez; let's all discover agile again (Score:5, Insightful)
You also need a lead developer who has the last word. Otherwise, forget about it.
Re: (Score:3)
There are a lot of desicions to be made when there is no superior solution - only different ones, which will affect future develeopment in distinct ways. And somebody has to make them arbitrarily.
Some people just cannot understand that.
Re: (Score:2)
Top it off with giving marketing the ability to speak in those standup meetings, and you have one hell of a recipe for fail...
Re: (Score:2)
Also add testers that don't really understand what the things they are testing are supposed to do to that meeting...
Re:oh jeez; let's all discover agile again (Score:5, Funny)
Re:oh jeez; let's all discover agile again (Score:5, Funny)
8am daily standup meetings to discuss what you did the day before and what your obstructions are to prevent work getting done.
12pm daily meetings to discuss what you've accomplished in the last 4 hours.
2pm daily meetings with project owners to explaining that you're following industry standard processes so just remain patient.
5pm daily meetings to plan what work you will get accomplished overnight before the 8am meeting.
Meetings will continue until morale improves.
Re: (Score:3)
Re:oh jeez; let's all discover agile again (Score:4, Insightful)
Re: (Score:3)
Emphasis on that. Crappy data leads to crappy conclusions. And her "data" is extremely crappy.
From TFA:
I count at least two WTF's in there. You wouldn't build cars engineered around blind people would you?
Also from TFA:
Re: (Score:2)
One of the main purposes of every flavor of formalized process is to enforce some minimum level of communication.
Ah, the coercion fallacy - a belief that forced communication is better than no communication. Forced communication will, when there's a lack of true data to communicate, lend itself as a channel for made up data.
You need to adjust the overall structure so communication becomes natural. And no, that does not mean "schedule meetings" and "demand reports". More like "put people who communicate well together", and give solo artists jobs where they have to solicit info from others, not the other way around.
O
Re: (Score:2)
You're both right.
It's one thing to have a group of top-end devs in one room. It's another to get them to play nice with each other. Not even talking about egos, per se... the ability to drop assumptions and actually start asking the other devs what they're up to is something that requires more than just knowing syntax and process to the nth degree.
Re:oh jeez; let's all discover agile again (Score:4, Insightful)
Is it just me, or is the interface the job of the architect, not the code monkey?
Re: (Score:2)
The fact that you used the phrase "code monkey" tells me you are clueless.
Re: (Score:2)
Is it just me, or is the interface the job of the architect, not the code monkey?
Except that any architect worth the title wouldn't think of developers as "code monkeys".
Re: (Score:2)
Whenever I'm in charge of a team, I take the architect role, and give the "code monkeys" specs so complete that the only bugs are if they didn't write to spec or if the customer changes his mind halfway through the work (the second happens far more often than the first).
Integration is the role of the architect, on any software team of more than one individual.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Just ignore the trolls. Sometimes even me. Responding to them doesn't do any good unless you just occasionally enjoy a good flame war for the fun of it, in which case you need to be lots ruder than that.
BTW; what rubs me up the wrong way about Sarah's posting is really this
Ever since Knuth designed web and espoused Literate Programming [wikipedia.org] there has been no possible way for a person properly
Re: (Score:2)
Every so often, I feel as though I have to respond to a troll. Not because I imagine I will change his mind but to demonstrate to lurkers that the community rejects such opinions.
Either Sarah is ignorant of this or...
Or I did an inadequate job of summarizing her talk, which was very good indeed. Because the point was not so much "People should talk" (well duh) but "Hack the bad code to see where and how the communication is failing to happen." I am quite sure that Sarah (who is a very smart person) is mor
Duh (Score:2)
I learned this from Captain Planet as a kid. Why does Sarah Mei just have to repeat the lessons of Earth, Fire, Wind, Water, and Heart?
Coding Architecture Models (Score:5, Insightful)
Isn't this exactly what MVP, MVC, etc... are meant for?
At that point it doesn't matter how crappy your code is, all it is is isolated to a single portion of a layer with inputs and outputs and relatively modularized as a result in regards to similar models.
Re:Coding Architecture Models (Score:4, Interesting)
At that point it doesn't matter how crappy your code is, all it is is isolated to a single portion of a layer with inputs and outputs and relatively modularized as a result in regards to similar models.
You're assuming that people actually put in that separation all the time. Just because you are using an MVC framework doesn't mean things are separated like they should be. Just like declaring something with "class" doesn't automatically make it (good) OO.
Re: (Score:2)
Everything depends on implementation, but sticking to an architecture is meant to make implementing the various components a lot easier. The framework is actually supposed to enforce the practices, so while its possible to deviate and not follow the pattern, ...I guess its really not that hard to make those choices, especially for expert programmers (ex. does it require behind the scenes computation? model!).
Re:Coding Architecture Models (Score:5, Informative)
No, and I have co-workers who I consider quite skilled, and none of them seem to know when to define an interface. Guys, enums and switches aren't replacements for subclasses.
Re: (Score:2)
Skilled in what exactly? (Score:3)
Because it certainly does n't sound like it is in object orientated program design. Being able to code is just one part of being a skilled programer, being a "rockstar" style coder may seem impressive but banging out pages of code at a time is never a good sign and I say this as someone who spent a good five years working this way.
It is only when you have to maintain your own code for years that you start to step back and think more because at the end of the day you can not code your way out of trouble, we
Re: (Score:3)
Re: (Score:2)
> enums and switches
> not using a function pointer.
ISHYGD care about performance.
Re: (Score:2)
If they don't know when to define an interface, they are most certainly not in "quite skilled" category. Don't confuse smart with skilled; it happens all the time.
Re: (Score:2)
There are multiple skills in this industry, and they have good command of a number of specialized technologies we use, multi-threading principles, algorithm performance, and a number of a non-design skills. Having one skill doesn't give another.
Re: (Score:3)
At that point it doesn't matter how crappy your code is, all it is is isolated to a single portion of a layer with inputs and outputs and relatively modularized as a result in regards to similar models.
You're assuming that people actually put in that separation all the time. Just because you are using an MVC framework doesn't mean things are separated like they should be. Just like declaring something with "class" doesn't automatically make it (good) OO.
Furthermore, not everything can be separated into those classifications. Take your average "Web2.0" website for example: The components of the MVC are spread out across HTML CSS JS and back end code. Sometimes it makes sense to put some controls in the view. Blind adherence to paradigms as a core business strategy can lead to unsynergistic blue-sky thinking that leaves the best and brightest ideas out of the loop. The best game plan is to go the extra mile to make sure that movers and shakers can inter
Re: (Score:2)
if nothing is dependent on any other module/progam, then the whole program does nothing.
of course if it's all designed in advance so that the interfaces are set to stone and so forth no problem.. but then the actual implementation is trivial and the actual "development" with all these same problems happened on the earlier stage. I'd say the problem comes when things are cut to pieces too much in advance for the sake of teamwork to begin earlier - and I go further and claim that companies do this so that the
Re: (Score:2)
Amen. I was once put as a lead programmer for an MVC project that was years behind schedule. What we found was appalling. And, I'm not kidding: They merged all the controllers in one giant class file, moved much of the views into the database (for no apparent reason) and used codewords throughout instead of meaningful class/variable names. They had painted themselves into such a corner that they were refusing basic feature requests because 'it wasn't possible' any more. They were big proponents for MVC
Re: (Score:2)
Overengineering is a common mistake in people who want to "do it right" and try to design resilience to every possible change. It never works, which is why Agile development emphasizes that building a "code inventory" is just running up a cost, not building an asset.
But not having a clue really doesn't help.
Re: (Score:3)
Code architecture is key, as is a common coding methodology among the team. Brilliant coders often are loners, and if you put them on a team, each may do what they normally do and do their own thing. You'll have a program written in several different languages, and an integration nightmare.
Here's an integration nightmare that continues to this day, thanks to lame computer language design. To reduce integration problems, a common architecture in EDA is to read a design into a common set of in-memory data
Re: (Score:2)
Re: (Score:3)
"You can still inherit from there classes, but you'll have to copy all the objects to new objects of your subclasses to be able to use them, doubling the memory required. "
You might try a shared_ptr instead so you may have less need to copy the objects instead of a pointer to them.
Or Lisp.
Re: (Score:2)
Re: (Score:2)
No. The first big MVC project I worked on had a project manager with that assumption. What happened is the Models were sparse because those writing them didn't anticipate everything needed by the Controllers and Views. So, a lot of what should have been in the Models was in the Controllers. Worse, the Views ended up having a lot of code that should have been in the Controllers and Models. Since those early days I/we've been very conscious about pushing as much upstream (V -> C -> M) as is reasona
Communication isn't the problem... (Score:4, Insightful)
Re: (Score:2)
if it were then projects like Linux would have collapsed a very long time ago.
To be fair, just because the people working on Linux have good (well, from what I've seen, decent) communication skills doesn't mean any random developer will.
Working on a solo project is much different than working on a group project.
Re: (Score:2)
Re: (Score:3)
Linux has been collapsing for nearly two decades now. The trick is to borrow ideas from judo so that when you get stuff done while falling.
I think what's really happening is that Linux isn't aiming for perfect or best. It has something practical it wants to get done and there aren't long arguments over the best architecture to use. Compare to GNU Herd which had very lofty idealistic goals and lots of debate over the best says to proceed. Ultimately having something ugly that does the job will win over s
Re: (Score:2)
What the flock is that?
Re: (Score:2)
My spell checker is biological and sometimes fails.
Re: (Score:2)
the basement dwellers hate people (Score:5, Insightful)
they want to sit in a corner far from other people coding in silence
they hate meetings and talking to people
so what you get is code that only talks to itself
Re:the basement dwellers hate people (Score:5, Funny)
they want to sit in a corner far from other people coding in silence they hate meetings and talking to people
And with good reason. Other people are annoying and I am immensely interesting to me.
Dream job, once upon a time (Score:2)
My dream job once upon a time would have been coding on something like VT220, green font on black background, terminal in a small office/closet.
Somehow my days are spent interacting with the people necessary to get the job done. Oddly enough, I actually enjoy it.
Re: (Score:2)
Yes and no. Interacting with others is fine. However it breaks down when it becomes "you must stop what you're doing and interact with them NOW".
translation (Score:3, Informative)
My team did not talk to each other and everyone went off and did their own thing. Then when it came time for integration it all went to hell...
Re: (Score:3)
This should be a good lesson about how group projects usually work in college; it's how all the ones I had worked out. One person does all the work, while the other person(s) claim credit and gets an equal grade even though they didn't do anything, or their contribution was very minor.
IMO, they shouldn't have group projects in college classes at all, because they always wind up like this.
Re: (Score:2)
IMO, they shouldn't have group projects in college classes at all, because they always wind up like this.
Or they keep them just because you learn something else; that it'll be like that in your future job.
Re: (Score:2)
Except that I've never had a job like that. In the "real world", projects are divided up so that each individual engineer gets a different portion of the task, and works on it himself. If one engineer doesn't contribute, it's entirely on him, and he gets a bad performance review, not the others. And management is constantly communicating with all the engineers to make sure the project is on-track; they don't just wait until the end to find out someone isn't doing anything or they're totally off-track wit
Formal meetings and formal processes (Score:2)
This is not to say formal processes and procedures are a problem just that bad ones are.
Sometimes they come from the heads of stupid people and well that can be understood. But often they come out of the heads of stupid evil people. They are too stupid to actually contribute so they come up with rules that they can then enforce to make other
I work in groups so it happens faster (Score:2)
Re: (Score:3, Insightful)
A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: ``How long will it take to design this system if I assign five programmers to it?''
``It will take one year,'' said the master promptly.
``But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?''
The master programmer frowned. ``In that case, it will take two years.''
``And what if I assign a hundred programmers to it?''
The ma
Re:I work in groups so it happens faster (Score:5, Insightful)
But WHY does it take longer when you add more people? The answer is "communication channels".
And they follow the formula of (n*(n-1))/2
So 1 person has 0 communication channels to maintain.
3 people have 3 channels.
5 people have 10 channels.
And if the EXACT same message is not present upon every one of those channels then problems start.
So the key is NOT to focus on 10 communication channels between 5 people but to focus on reducing the scope as quickly as possible so that fewer people are needed. And the means that your best programmers can spend more of their time programming and less on maintaining communication channels.
Re: (Score:2)
Re: (Score:3)
Unless the division of tasks is done in a pathologically bad way, not everybody has to talk to everybody else about everything.
Still, kudos for not [mis]using "exponential".
Re:I work in groups so it happens faster (Score:5, Interesting)
No, you are totally wrong, usually people don't bother communicating, so you don't lose a lot of time on communication.
It takes longer because of Ringelmann's effect, and this had been measured in 1914, by measuring efforts.
Here is the original article in french: http://gallica.bnf.fr/ark:/12148/bpt6k54409695.image.f14 [gallica.bnf.fr]
When you have 1 guy, he works at 100%, but when you add 1 guy, you get 93% of their combined force.
Here is the table from 1 to 8:
1 => 100%
2 => 93%
3 => 85%
4 => 77%
5 => 70%
6 => 63%
7 => 56%
8 => 49%
With 8 people, you get the results of 4 people !
In fact, when you add people in a team, everybody reduces his level to the supposed level of the group.
If I'm alone, I think I'm the best, so I'll work at my best level.
If there is another guy, I'll work according to our common level, so I'll reduce my effort.
When you have a team, the team works at the lowest common level.
You can also see that when people walk in groups, they walk together at the slowest speed.
Re: (Score:2)
This table only deals with the situation where they all work on the same thing.
I recently had a crash project. If it didn't work out, the company would be forced to stop work until the project was completed. We were talking millions of dollars per day here, so the project was a tad urgent.
First, the other information analyst was removed. Then I did the requirements. While they were being completed. a testmanager came in and started writing testcases on the requirements. A programmer came in and did mock-ups
Re: (Score:2)
I think that you were lucky.
Luck has a great importance in software projects, but of course, luck is not random.
I think that the most important fact that you don't mention is that everybody in your team was motivated, they felt that they had some power to do things.
When you remove the sense of power, people lose motivation and produce some half-assed work.
Then, I believe that you are an ex-programmer, and most of the managers I know pretend to be able to code, but when I check, I see that they are pretty ba
Re: (Score:2)
I think that's a fair summary.
In my previous project I was in charge as architect/information analyst and lead designer, supported (and not hindered) by a very competent project manager who never got in my way but just made sure everyone had what he needed. In my current project things are very different - to the detriment of all.
Re: (Score:2)
So a basketball team with 4 people will tie a team with 8 people 50% of the time? (all individual skill levels being equal)
Or a tug-of-war competition between two teams (one with 4 people and one with 8) of people with similar physical builds will be a tie.
I always took Ringelmann's findings as support for "work expands to fill the available time" rather than an upper limit on a group's capabilities.
Re: (Score:2)
Good point !
But in a sports team, the manager has some other players on the bench, so when he sees that a guy doesn't do his best, the player will be replaced instantly.
As I explained in another answer, what is important in a team is the sense of power.
If every member thinks that he can produce something significant (like in a sports team), then everybody will be motivated and will do their best.
If somebody thinks that his effort will be insignificant, he'll quietly reduce his effort, and sometimes that mea
Re: (Score:2)
When you have 1 guy, he works at 100%, but when you add 1 guy, you get 93% of their combined force. [...] With 8 people, you get the results of 4 people !
No wonder the pyramids took so long to build!
Re: (Score:2)
Re: (Score:2)
I love this type of information.
Frankly, I think we should have a series of Slashdot headlines around software development and what people have found works. This crowd could provide very meaningful answers to such questions. Then summarize the best ideas and let people have at them again...
Myself, I'm on a three developer team (3 channels, with lots of constant interaction) with a very technical manager (he always questions naming conventions and reviews our code and structure constantly, and he knows wha
Re: (Score:2)
You get a group of 10 together because you have a 400 man-hour project due in a week, not to make your code better.
If you think 10 developers can complete a "400 man-hour project" in a normal work week, then you need to read up on Amdahl's law with inherent overheads of parallel processing, and realize... that humans are a lot less efficient, and a lot more overhead is required managing the parallelism
A particular coding task doesn't have an intrinsic amount of time that it can be done in, that you ca
Re: sub-par teamwork (Score:2)
If you've ever worked on a team you can probably recall a time when, as a group, you produced work that was not as good as any one of you could have done on your own. Sarah Mei had this sort of sub-par teamwork experience, ...
Wow, Sarah Mei has worked with Congress?
Nobody saw that coming... (Score:2)
And, as it turns out, team communication is the heaviest dependency of all.
That's pure brilliance. Groundbreaking stuff.
Real developers don't "generate" code... (Score:2)
...they write it. Clicking a button to convert your architect's UML to Java isn't the same. Perhaps that's the problem here, but I didn't bother to RTFA because it didn't sound very interesting.
Who says they were great coders? (Score:4, Interesting)
Just because they name drop does mean they are great coders, only that they are great at self promotion. Who's to say that some silent but really competent coder wasn't responsible for the code they take credit for? I think what you saw was not "great coders can't work together," but instead, "great projects have many unsung heroes."
EGO, more than communication. (Score:2)
EGO, EGO, EGO. Every time I have seen this, at its heart, its ego. The just plain stupid notion that: "im the smartest person in the room, I dont need to confer with anyone cause im so good". I would rather work with 6 humble jr. dev's then 6 senior meglomaniacs any day of the week and twice on sunday. Sure the code quality is also going to be suspect but at least, if say a rewrite of a module is needed, people are willing to just do it rather than bitch about why its the other modules part because there wo
Re: (Score:2)
I sometimes don't mind people like that as long as they can carefully justify their choices. People forget that code is largely for people (to read), not computers. The computer doesn't "care" how you organize code; it just follows instructions. Code organization is a matter of human readability, and if the egomaniac can justify their decision in terms of that, then I'll respect them.
H
Re: (Score:2)
I'm dealing with this ego shit right now. There's this developer who is highly regarded by his boss so he gives him complete free reign to do what he likes and rarely ever confers with his colleagues because he thinks he's smarter. He may actually be smarter but it doesn't mean he's a better coder. He makes common coding process and design errors all the time. He's fairly young so it's not unexpected but it's still irritating as hell because his decisions often effect the rest of us.
Re: (Score:2)
Maybe age shouldn't come into it but reality dictates otherwise.
maybe they just don't care about this project (Score:5, Insightful)
Simple formula for code quality (Score:2)
code_quality = time * talent * experience * just_dont_care_factor
If you find code_quality nearing 0, that often means they just didn't care. [youtube.com]
Excellent *individual* programmers (Score:3)
They may have been excellent individual programmers capable of producing works of art on their own, but the mindset for working in a team environment is completely different from that required for individual project work.
However, I blame not the developers, but the project management team for failing to realize that even the brightest people in the world need to be organized and have to structure their code properly to be effective. Far too often management takes the attitude that if they just hire "the best" and let them loose, miracles will happen.
Well, they don't.
In fact there is an entire book written about such management mistakes, in particular the fact that the more people you add to a project, the more effort and time it takes in total to complete. A little known text called "The Mythical Man-Month."
Perhaps you've heard of it?
If you haven't, you definitely need to read it.
Same reason "All-Star" teams suck (Score:2)
You can get a bunch of guys that are really good on their own teams all together on the same team and end up with a team that's worse than the "lesser" teams they came from.
Sports history is littered with this phenomenon.
Re: (Score:2)
Yup.
All too often there are multiple "right ways" of going about things, like cooking. Or coding. It's not a problem if you boil your potatoes first, then peel them. Or if you peel, then boil. But if you have to reach a compromise and only peel half of them, the result is sub-optimal.
If you have to pass something on the road you can go around it to the left or the right. Taking the middle because you had to compromise seldom works out.
That's why more than one captain on a ship is a bad idea. Even two brilli
Configuration Management (Score:2)
I call BS (Score:5, Insightful)
While those things she list are important, it sounds like this woman actually worked in an environment where the low level architecture wasn't controlled or defined by someone with any experience with long term maintenance.
There are a lot of really good coders, but the skills required to properly define high level interfaces between subsystems is _NOT_ something all of them posses, even though the vast majority either think they do, or fail to understand the importance of defining project API's for isolation.
This isn't to say that people with the term "architect" in their titles get it any better. In many cases they tend to get it wrong because they are too decoupled from the actual coding portions.
Its also something that is nearly impossible to bolt on after the fact. The last thing your project manager wants to hear, is that 3/4 of the project needs to be rewritten (or refactored to the point its not recognizable) because of some stupid problem with component isolation.
So, how to you identify bad architecture?
If your team can't isolate and troubleshoot the vast majority of bugs quickly (less than a hour).
If the common answer to features, is that some large portion of the system needs to be rewritten or refactored.
If the system is brittle, and errors aren't contained to smaller subsystems.
If requirements changes tend to touch a lot of different system components.
The list goes on, but I firmly believe that bad architecture is the problem in a lot of cases where people claim crappy code, or failures because the product is buggy or is not agile enough to respond to market needs.
Collective agreement (Score:5, Insightful)
One of the most important things when it comes to avoiding a group creating a mess is to have collective agreement on the architecture and design and the divisions and interfaces between components. Everybody doesn't have to agree that this way's the best way, but they have to agree that it's acceptable and they'll write to it. This goes both ways: you have to acknowledge that you'll follow the design even when you don't agree with it, and you also have to acknowledge that the other guy (who isn't getting his way) has valid points even though you're doing it your way instead of his.
NB: the above is why my mantra is "I am not a rock star. I am a professional.". I'll argue vehemently for what I think is the best way to do things, but in the end I need to write code that fits well with the rest of the system even if that code isn't technically "the best way".
It's called management (Score:2)
Management is it's own freaking science FFS... and large systems architecture is, too. Just because someone is a top tier programmer doesn't mean they can run a project to save their lives. I'm a LOUSY programmer... but I have managed hundreds of programmers on dozens of concurrent and many times linked projects and kept it together... because that's my skill set.
Why is there crappy code? (Score:2)
All of these logistics
Software Engineering doesn't work (Score:2)
Despair.org has the poster [despair.com] for this one. None of us is as dumb as all of us. This is one of those dumbass articles intended to make programmers feel bad because we're not schmoozers and claim our code suffers as a result. It doesn't. The code suffers because bosses assume you can simply harness programmers together, probably under some MBA, assign them bits of the job ad-hoc, and you'll get miracles.
software architecture (Score:2)
Conway's Law (Score:2)
It's the environment, stupid... (Score:2)
I'd bet this was the standard cube farm, or worse, the open space "collaborative" environment where every conversation carries, making it impossible to focus without some headphones and some music. And nothing says "Hey, I'm approachable" like being hunched over a computer, heads bobbing to the beat.
You want to improve software productivity, start with the environment. Offices. With doors. That you can knock on, close and have a real conversation without distracting others.
Remember Pair Programming? For a w
Smart developers != smart designers. (Score:2)
Being a smart developer does not mean being a smart designer.
Being a smart developer means to make a program that has good performance, reasonable number of bugs, can easily be read by other people, etc.
Being a smart designer means code can be easily extended, patterns applied consistently across code, good modularization, can easily be refactored, low coupling etc.
What most projects, if not all, lack is software designers, i.e. people who design APIs, modules and interfaces of high quality.
In most cases, t
Social programming... (Score:2)
"...forces guiding our day-to-day software design decisions are social..."
Joke that's not quite funny: Quit hiring "brogrammers" and hire more "aspies" who totally don't get social at all, and this effect goes away. Have I used enough of this weeks Slashdot article buzzwords?
Frankly, from reading the article, it seems that there is a poor understanding of component interface contracts. This is like thinking you comply with POSIX because you have a stat(2) system call, but all the structure members are mis
There should have been an architect (Score:2)
or "technical lead" or "team leader" or whatever who was organizing how all the pieces fit together, and reviewing the team members' designs to ensure they're compatible with each other and the rest of the system.
It's a management failure that they didn't assign somebody to be in that role (or otherwise have the team choose who within the team will be the technical lead).
I'm thinking part of it is Broken windows theory (Score:2)
Re: (Score:2)
Re: (Score:2)
There's a balance: if you don't have any comments or documentation at all, how are you going to remember what you were thinking or intending 6 months later when you need to fix something, or even 3 weeks later? When I'm writing my own code for my own personal use, I don't exactly create extensive documentation, but I do as a matter of habit put comments at the beginning of every function describing its use, and in-line comments to describe what each code block does, because this proves invaluable later whe