Are you good at Maths?

[Irwell]

To be honest now you've described the project's size, it's a little clearer why you would have functions with loops moving into the several hundred line mark.

Again, though, my preference would be to work in the same way even with a smaller project, mainly for some kind of continuity.

True, and those are the cases whereby index variable naming is a logical thing to do. I think we're arguing from different scopes here and trying to apply a universal rule. You're arguing from the several million line project ideal where I'm arguing from the run of the mill project ideal. Like anything else, you adjust to suit. I'm sure that if you had a single loop somewhere, maybe iterating through a connection array or something trivial, you wouldn't tick up a fuss for int i?

If someone is sticking together a short script for a one-off task to maybe assure the data integrity of a part of the database or to correct something that has gone wrong then I would have no issue with it. The developer would be working alone on the code, though obviously the design authority and testers would be involved, and there would be little chance of any situation where the code was reused by another developer. If, however, it was in part of the system itself then it would have to be changed, not through some OCD behaviour on my part but because that is what both our employer and the client want. If we worked somewhere with a naming convention that allowed for the use of i then obviously there would be no problem.

The JavaDoc/Doxygen style is something that I do find attractive and has lots of uses for. Like anything though, it has to actually be used well otherwise it detracts rather than adds to understanding. Do you guys legislate on commenting at all?

Not particularly, just that anywhere the functionality isn't clear from the code, for example you perform four functions in a set order but there is no indication why they are performed in that way, then there should be a comment explaining it. If the functionality is clear then there is no need. Obviously, though, we do have predefined header comments that go along with each class and function.

I tend to "think" in Linux naming conventions originating from C as that's what I learnt with. So for me, I would use things like count_online_users() rather than iCntOnUsers()

To quote Linus here on the kernel naming conventions:

C is a Spartan language, and so should your naming be. Unlike Modula-2
and Pascal programmers, C programmers do not use cute names like
ThisVariableIsATemporaryCounter. A C programmer would call that
variable "tmp", which is much easier to write, and not the least more
difficult to understand.

LOCAL variable names should be short, and to the point. If you have
some random integer loop counter, it should probably be called "i".
Calling it "loop_counter" is non-productive, if there is no chance of it
being mis-understood. Similarly, "tmp" can be just about any type of
variable that is used to hold a temporary value.

Again, our naming convention is kind of a hybrid. For functions we would use a more descriptive form, but in camelBack notation, i.e. countOnlineUsers(), but we would include the scope of the function in the name too, i.e. mcountOnlineUsers().

I would agree with Linus, calling a loop counter "loop_counter" rather than i would be meaningless. Every man and his dog who has looked at some code knows that i is a loop counter, so it would just be a waste of time. Also, from a kernel perspective they would want to reduce memory use as much as possible and so not be defining variables unnecessarily. User space applications have much fewer such restrictions as the memory usage is much less important these days and it was never my argument that the descriptive name for the variable should just be something like "loop_counter". That simply describes what the purpose of the variable is, not what the meaning of the data within it is.

I think our thoughts are different because you're a project manager and I'm a developer. I expect other developers to understand my code simply because anybody who has coded for more than a few minutes (and some that haven't) can probably work out what "tmp" mean in the context of the overall. You don't have the luxury of presumption and when that new hire who didn't quite tell the truth about his experience bombs an entire module because of it, it's you who gets shouted at and not me.

I still prefer to think of myself as a developer!

 

[Irwell]

Ok cheers Damo. 6 phases rather than 6 subdivisions.

Yes, I was talking about the subdivision into roles as we would have different people involved with each of those phases. For us they also aren't really strictly defined phases as around the design/implementation phases things become a lot more fluid. They are, however, different areas of responsibility and management of the project from a technical perspective is pretty much subdivided along those lines.

 

[Irwell]

That's a very good sign. I presume they're Architects and they have a Chief Architect who is responsible for delivery of the overall solution.

Design authority and systems architecture lie with different people. The design authority lies with the client as the system is built to their specification. Their design is basically the business logic for their processes. The systems architects then turn this business logic into an object model, complete with descriptions of each bit of functionality. The functional descriptions are then turned into code by the developers, within the confines of the object model they have been given. Yes, we have an architect with overall responsibility for the model.

Diktat does not mean to say that a policy is correct. As a Roman Catholic I am very aware of this.

Coding standards or more preferably coding guidelines are good practice. The issue is the extreme strictness and policing of the policy.

I'm starting to think the Vatican is involved in some way and the project health rating has just nosedived.

<tongue_in_cheek>No, there aren't any young boys working at our place!</tongue_in_cheek>

We're actually fairly relaxed when it comes to allowing them freedom to decide the best way to implement the functionality. It's only really the naming convention and adherence to the object model that are strictly enforced and this is because our documentation is formed on the basis of it.

If programmers only get involved when provided with mature object models, the job is over 80% done. Code generation tools will even generate the classes, attributes and methods automatically from the design.

In between an extremely strict coding standards policy and the provision of object models from architects, I'm not sure how much freedom to manoeuvre they have and essentially Damo is right.

Yes, they are provided with essentially an empty shell for the whole application. Their job is to make each function do what it's description says it's supposed to do.

If you're project manager with involvement in HR and solution creation, you must be a significant risk and monitoring/reviewing yourself in the risk register.

I don't get involved in HR matters at all, I was just speaking hypothetically. I do keep a finger in the architecture pie, though, mainly because that's the background I came from and I find it useful to know how it's designed to help see if the project is still on track.

Yes, I have plenty of Project files dotted about and I can tell from these, but it's nice to be able to step back and look at the house and see that all we have left is the roof tiles.

Yes but is the Client (probably organisation) the same as the Customer (also probably organisation).

I hope they are!

The client is a specific department within the customer.

It's standard business practice to transfer all the non recurring costs onto a mass manufacturing run.
e.g. Cars.

I've tended to find that in our industry it's even more common to transfer the costs onto the client! Not that I'd ever tell them that...

See my comments above in part. Returning to requirements definition phase and changing the business logic would add mindboggling levels of extra cost.

It quite often does, which is why design authority lies with the client. If the requirements need changing then the design was wrong, and as design authority the responsibility for costs incurred lies with them. We can't just change the design ourselves as if the change was wrong we would then incur the costs for not adhering to the design they gave us.

Most of the time it is only small things, though, so once the design authority authorises a change this is passed onto the appropriate architect who simply updates the description of one of the functions. It's very rare that the design change is such that it requires an object model change, unless they are asking for a whole new bit of functionality.

Fair point although you'll never convince me that a WBS involving Architects and Programmers is better than one using a hierarchy of Systems and Software Engineers at different levels of the System Architecture.

I think the main difference is cost. The majority of work is done at the programmer level actually padding out those functions. The less responsibility they have, the less we have to pay for their services. People working at a systems architecture level are the ones on the good money so we get as few people involved at that level as we can.

 

[pauldominic]

That's a very good sign. I presume they're Architects and they have a Chief Architect who is responsible for delivery of the overall solution.

Design authority and systems architecture lie with different people. The design authority lies with the client as the system is built to their specification. Their design is basically the business logic for their processes. The systems architects then turn this business logic into an object model, complete with descriptions of each bit of functionality. The functional descriptions are then turned into code by the developers, within the confines of the object model they have been given. Yes, we have an architect with overall responsibility for the model.

Its very clever of your company to give the customer design authority.

If we did that in defence, nothing would ever appear.

Diktat does not mean to say that a policy is correct. As a Roman Catholic I am very aware of this.

Coding standards or more preferably coding guidelines are good practice. The issue is the extreme strictness and policing of the policy.

I'm starting to think the Vatican is involved in some way and the project health rating has just nosedived.

<tongue_in_cheek>No, there aren't any young boys working at our place!</tongue_in_cheek>

We're actually fairly relaxed when it comes to allowing them freedom to decide the best way to implement the functionality. It's only really the naming convention and adherence to the object model that are strictly enforced and this is because our documentation is formed on the basis of it.

Sex abuse wouldn't come into it, but there are many other strings to their bow.

If programmers only get involved when provided with mature object models, the job is over 80% done. Code generation tools will even generate the classes, attributes and methods automatically from the design.

In between an extremely strict coding standards policy and the provision of object models from architects, I'm not sure how much freedom to manoeuvre they have and essentially Damo is right.

Yes, they are provided with essentially an empty shell for the whole application. Their job is to make each function do what it's description says it's supposed to do.

If you're project manager with involvement in HR and solution creation, you must be a significant risk and monitoring/reviewing yourself in the risk register.

I don't get involved in HR matters at all, I was just speaking hypothetically. I do keep a finger in the architecture pie, though, mainly because that's the background I came from and I find it useful to know how it's designed to help see if the project is still on track.

Yes, I have plenty of Project files dotted about and I can tell from these, but it's nice to be able to step back and look at the house and see that all we have left is the roof tiles.

It's a serious point. Disable the Vatican by changing the standards to guidelines and let the programmers do peer reviews of one anothers code.

Resist the temptation to get involved. You're the project manager.

Yes but is the Client (probably organisation) the same as the Customer (also probably organisation).

I hope they are!

The client is a specific department within the customer.

Ok.

It's standard business practice to transfer all the non recurring costs onto a mass manufacturing run.
e.g. Cars.

I've tended to find that in our industry it's even more common to transfer the costs onto the client! Not that I'd ever tell them that...

I used to work in the nuclear industry (Sizewell 'B' and Vanguard class submarines).

Variations to contract were charged at whatever rate we thought we could get away with.

See my comments above in part. Returning to requirements definition phase and changing the business logic would add mindboggling levels of extra cost.

It quite often does, which is why design authority lies with the client. If the requirements need changing then the design was wrong, and as design authority the responsibility for costs incurred lies with them. We can't just change the design ourselves as if the change was wrong we would then incur the costs for not adhering to the design they gave us.

Most of the time it is only small things, though, so once the design authority authorises a change this is passed onto the appropriate architect who simply updates the description of one of the functions. It's very rare that the design change is such that it requires an object model change, unless they are asking for a whole new bit of functionality.

Fair point but if the industry / market is volatile, this could still get expensive.

Fair point although you'll never convince me that a WBS involving Architects and Programmers is better than one using a hierarchy of Systems and Software Engineers at different levels of the System Architecture.

I think the main difference is cost. The majority of work is done at the programmer level actually padding out those functions. The less responsibility they have, the less we have to pay for their services. People working at a systems architecture level are the ones on the good money so we get as few people involved at that level as we can.

If you employ Systems Architects and Programmers, I don't think they would be any less expensive than a Software and Systems Engineer breakdown.

Finally, I don't like the idea of dividing the project lifecycle into subdivisions.

The phases are lifecycle maturity gates rather than sub-divisions.

 

[burning blue soul]

6 -1 x 0 + 2 / 2 =?

settle this one for me.

 

[ali benarbia's studs]

6 -1 x 0 + 2 / 2 =?

settle this one for me.

5 for me?

 

[roaminblue]

7

edit...or 1....if you've written 6(-1*0)+(2/2)

 

[ali benarbia's studs]

7

oh so now i m a fat **** and i m stupid too ????

 

[mindmyp's_n_q's]

6 -1 x 0 + 2 / 2 =?

settle this one for me.

Can I just ask (as there is an extra space at the start) are you asking.

6 (minus) 1 (multiply) 0 (add) 2 (divide) 2 =?

Or have you written

6 -1(this being minus 1 the number) (multiply) 0 (add) 2 (divide) 2 =?

if it is the first one I am going for 7

bodmas

b - no brackets
o - no squares or roots
dm - division and multiplication left to right -1 X 0 = 0 then 2 divided by 2 = 1
as - addition and subtraction left to right you are left with 6 + 1 = 7

Even google agrees (they put the brackets in though)

<a class="postlink" href="https://www.google.co.uk/search?q=6+-1+x+0+%2B+2+%2F+2&aq=f&oq=6+-1+x+0+%2B+2+%2F+2&aqs=chrome.0.57&sourceid=chrome&ie=UTF-8" onclick="window.open(this.href);return false;">https://www.google.co.uk/search?q=6+-1+ ... e&ie=UTF-8</a>

 

[bobmcfc]

6 -1 x 0 + 2 / 2 =?

settle this one for me.

I got 3.5

But I'm good at spending on a budget