|
Just wondering. Do you/team follow common coding standard/convention before starting implementations? I think this should be basic else it will be night mare to follow each dev code.
Wonde Tadesse
|
|
|
|
|
Never experienced that, as I work on a small company, and I am currently the single developer of the 1 big project and 1 smaller one (getting bigger though).
Sometimes I feel I could use some feedback, as I never really was "under the wing" of a more experienced developer, and kind of "learn" things on the fly without any critique by anyone else than me.
But yes, 1 day coding and 3 days circle-jerking around it sounds a bit too much.
|
|
|
|
|
I don't like them -- and not for personal reasons, but for a larger one: they dilute the engineer's sense of ownership of his work.
I struggle to see to it that my people get tasks that are whole. I want them to be able to point to whole, important applications and say, "That's mine. I did that." There's nothing in the world that confers job satisfaction like that sense of personal accomplishment. Outside meddling, whether delivered as mandatory reviews or in any other fashion, reduces one's ability to feel that proprietary pride.
So I tell them, from Day One under my supervision and as often as necessary afterward:
"Your responsibilities are yours. If you need help, it will be up to you to say so -- and don't be shy about it. I won't think less of you for doing so. I'll always take you seriously. I'll bend time itself to get you what you need, including my personal assistance with really thorny problems. If you want something reviewed, tell me and I'll review it, or arrange a review session for you if you prefer. But unless you ask, except for an occasional request for status, I plan to leave you in peace."
This unsettles a few persons who've come to my group from process-intensive environments. They've been bludgeoned with ISO 9000, or the CMMI, or similar windy nostrums composed by idle academics and professional busybodies until they're paralyzed by a sense of continuous, unrelenting exposure to scrutiny and criticism. All you can say to such a person is "You're in my group because I want you here. That's because I think you're good enough to be one of mine. Why shouldn't I trust you? Just give me a few words of status once a week so I can compose pabulum enough to placate the chair-warmers and spreadsheet-fiddlers above me."
It works. Really.
(This message is programming you in ways you cannot detect. Be afraid.)
|
|
|
|
|
Fran Porretto wrote: they dilute the engineer's sense of ownership of his work.
I think for most software teams this is a good thing.
It's certainly better than "I'm not going to touch John's code, I'll rather work around it", Or "Waaaaah Jill touched my code!". And whether it be unrelated wolf attacks, the underside of the bus or the sunsets on Maui, it would be irresponsible for most shops to not enforce shared ownership. Even with perfect planning and documentation, having another developer get familiar with a new code base can take months which can be critical to the product and the company.
Of course, it can deteriorate into "It's not my fault, I guess Jill broke it again.". If it's impossible to get rid of that, it may be better to have big walls between the developers. That's not a good thing, though.
Shared ownership is something different from shared responsibility. Someone is responsible for the whole product, and everyone working on it is responsible for the tasks assigned and not breaking other people's stuff.
But even if it was, I don't see that it takes the pride of ownership away. There are still features and pieces where everyone knowns "peterchen did that!". We have long-lasting products that have grown out of a few KLOC of mine hacked together in a week. In a way, it's still my baby.
Fran Porretto wrote: They've been bludgeoned with ISO 9000, or the CMMI, or similar windy nostrums
composed by idle academics and professional busybodies until they're paralyzed
by a sense of continuous, unrelenting exposure to scrutiny and criticism
A modern car consists of hundreds of thousands of parts, provided and verified by hundreds of suppliers and sub-sub-sub-suppliers all around the world.
If you want to find out that one out of a million spontanously combusts because five years ago someone decided to replace XHF4122L2 with XHF4122L2GE, you need that sh*t.
There are places, e.g. a tight team with responsible and motivated where this is not necessary. Those seem to be suited to shared product ownership, though.
|
|
|
|
|
Fran Porretto wrote: I don't like them -- and not for personal reasons, but for a larger one:
they dilute the engineer's sense of ownership of his work.
A professional developer recognizes that the company owns the work and that if the company fails then the developer fails. If a developer is only responsible for their own work then they will feel that they need not comment on actual or perceived failures of others. Matter of fact they might come to believe that they should not do so.
Fran Porretto wrote: Outside meddling, whether delivered as mandatory reviews or in any other
fashion, reduces one's ability to feel that proprietary pride.
I certainly feel pride when my work results in no production bugs.
And utilizing all possible avenues even those with potential flaws to improve that goal leads to satisfaction. And it leads to company sales which lead to more money in my pocket. And that is very satisfying.
Fran Porretto wrote: until they're paralyzed by a sense of continuous, unrelenting exposure to
scrutiny and criticism
Projects fail that have been implemented in C++, Java and C#. However that is not a condemnation of the languages. It is condemnation of the way in which the implementation was done.
Same exact thing applies to process control procedures. Poor implementations are not a commendation of the process methodology.
Fran Porretto wrote: It works. Really.
So does effective implementation of process methodologies. There is actual studies that prove it as well. One need only review ACM/IEEE articles to find them. And one can find the objective measured improvements as well. Versus subjective opinions.
|
|
|
|
|
Wow, code reviews.
I led a project once that implemented code reviews. They were extremely successful at removing bugs (as measured by comparison to other projects at the same company). We overcame the social problems with code reviews and got to the point where the whole team (I'm pretty sure) valued them. As a result of this experience, I am a total believer in code review.
We did heavy-duty code reviews that involved at least 3 people and a physical meeting. There's all kinds of software for code review, but automated software leads to superficial review, because no one is watching that you took it seriously and didn't just quick-scan the code and click the "approved" box.
Code review is expensive. It took about a calendar week of work to get a block of code (typically one class) spruced up for review, printed on paper, distributed, the meeting held, and the review changes incorporated. This time measured the difference between the code after you finished working on it and the debugged, commented, beautiful code that met the review criteria. In other words, people are deceiving themselves when they think their code is done. Code review cuts through that deceit. (Unfortunately, we didn't realize beforehand the effect that getting code really done would have on the schedule, so we went long).
Code review is socially hard. That's why the first two or three modules we reviewed were my own code. I was a senior person with good coding experience and a thick skin for editorial comments. Sure enough the first couple of meetings I got teased a little. I said, "Next week it's going to be your turn in the spotlight. Lets keep this professional because we don't want to set a precedent of teasing people." This worked very well, teaching people at the same time to have thick skins about review comments, and to be respectful of their teammates.
We had a very formal process. We handed out the code for review on paper at least 24 hours before the meeting. If the code wasn't ready by then, the meeting was cancelled and rescheduled. We required each person who attended the review to actually read through and mark up the code. When we started a meeting, we asked, "Raise your hand if you read and marked up the code." If there weren't at least 2 people (plus the author) who raised their hand, we cancelled and rescheduled the meeting. This put significant social pressure on participants to do the homework, which resulted in very insightful reviews that found many real bugs. We kept and archived minutes. The author published the minutes directly after the meeting, including all the review comments. The author used their judgement to edit the comments, removing trivial discussions and bullshit change requests. Since we had established a professional attitude about reviews and teamwork in general, this didn't result in any problems. I sent out the first few minutes to establish a professional standard.
I published a list of the first few reviews worth of change comments. These comments, turns out, read like a coding standard, and reflected good C++ style (big-three, delete-what-you-create, RAII, that kind of thing). As a result, after the first two weeks, none of these issues EVER arose in review, because nobody wanted to be busted for stuff we already agreed needed to be fixed. Coding standards are good. Coding standards that come from peoples' own comments, so they buy into it, are wonderful.
Code review raised the whole team's game, and brought the less experienced devs up to a rather high standard. That week of prep-work I talked about got to be more and more self-review.
We had a commenting standard and a coding standard. Compliance was very good compared to other projects I've worked. Nobody wanted to be busted for leaving <add comment="" here=""> blocks in their code. So the usability of the sources was good.
During the term of the project, our company decided to do ISO-9000. As part of this process, we had to actually measure our defect rate, so we knew how we were doing with respect to other projects. We had the lowest delivered bug rate in the company, I'm rather proud to say.
|
|
|
|
|
I agree, in my field we conduct reviews, mainly because we have a very small team that is composed of 2 junior developers, with 2 seniors. The seniors review each others code and the we together review the juniors code.
This has lead to an increase in the quality of the software that we write, if and when i move team and or companies, I will be taking the process of code reviews with me as much as I am able to.
James Binary Warrior.
|
|
|
|
|
SeattleC++ wrote: We had the lowest delivered bug rate in the company, I'm rather proud to say.
And it appears you also effectively implemented a process methodology.
|
|
|
|
|
I'm currently working for a large financial corporation who are trying to maintain a CMMI Level 3 http://cmmiinstitute.com/[^] so formal Peer Reviews have been introduced across the board (in theory). Many of us have been trained in how to perform them properly - on both the Moderator and Inspector/Reviewer level.
If you're having to waste 3 days on a single review then the process you're being forced down might need some attention - Work Product Inspection shouldn't take more than 2 hours of anyone's time (otherwise too big a product/nit-picking in detail/PM expectations too high) and the meeting should be less than 2 hours.
I have to say I was very sceptical at first but it definitely works - and having the formal structure actually keeps the time-wasting to a minimum - the moderator keeps things moving along - the key phrase from our training module is "Focus on Finding Defects: Only DEFECT explanation is allowed" - helps keeps the "my way is better" comments at bay 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
