Programmers are the production line workers of the 21 Century. It's not programmers that are needed but software engineers and the two terms are not synonyms. Software engineers analyse the problem, create designs and document them, create models (e.g. UML), use patterns, define APIs, integrate existing software components and the like. Once you've done all that properly the rest is just a mechanical process that any reasonably competant individual should be able to undertake. You need some management s
I have little to no respect for people who toil away at UML diagrams. They're nothing more than busywork for coders and eye candy for higher-ups.
Honestly, if you're asked to make such a diagram, you're the only one who's going to understand it.
Not to say that I'm against sketching-out behaviour on a napkin at the pizza parlour, but why would anyone spend time connecting diamonds and rectangles when they could be making demonstrative code?
I've gotten a lot more mileage out of primitive code with meaningf
I have little to no respect for people who toil away at UML diagrams. They're nothing more than busywork for coders and eye candy for higher-ups.
And I have no respect for coders who just sit and code with no real sense of direction, no design, no idea of what the requirements are etc. I've had to maintain too much shit code from incompetent coders who have then gone and left the company leaving a steaming piles behind. And often it is me who does it as I seem to be one of the few people in the company who can decipher the mess. This is why I insist on properly designed code.
Having said that I do not insist on a full UML model but at least package, object and state diagrams so you know how the various software components tie together.
Honestly, if you're asked to make such a diagram, you're the only one who's going to understand it.
That's a training issue. At work I'm not the only one who understands it.
Not to say that I'm against sketching-out behaviour on a napkin at the pizza parlour, but why would anyone spend time connecting diamonds and rectangles when they could be making demonstrative code?
In my case it's pieces of A3 paper. I just formally document those designs that are needed to be formally documented and only the parts of those designs that need to be formally documented. These documents are usually associated with a programmers guide and example code.
I've gotten a lot more mileage out of primitive code with meaningful outputs* than I have from tracing my way through a UML tree.
I don't believe either on their own are useful so supply both. As I've said above I don't go for the full formal UML model but use the syntax for some diagrams.
* ie. skeleton code that tells you what it's doing at each step ("I just made BankAccount 'steve'", "fetched 'steve's info", "incremented 'BankAccounts'")
That explains a lot. When you are writing software for real time systems like set top boxes you need to be more formal with your working methods.
The subject says it all (Score:5, Insightful)
Re:The subject says it all (Score:2)
Honestly, if you're asked to make such a diagram, you're the only one who's going to understand it.
Not to say that I'm against sketching-out behaviour on a napkin at the pizza parlour, but why would anyone spend time connecting diamonds and rectangles when they could be making demonstrative code?
I've gotten a lot more mileage out of primitive code with meaningf
Re:The subject says it all (Score:2)
And I have no respect for coders who just sit and code with no real sense of direction, no design, no idea of what the requirements are etc. I've had to maintain too much shit code from incompetent coders who have then gone and left the company leaving a steaming piles behind. And often it is me who does it as I seem to be one of the few people in the company who can decipher the mess. This is why I insist on properly designed code.
Having said that I do not insist on a full UML model but at least package, object and state diagrams so you know how the various software components tie together.
Honestly, if you're asked to make such a diagram, you're the only one who's going to understand it.
That's a training issue. At work I'm not the only one who understands it.
Not to say that I'm against sketching-out behaviour on a napkin at the pizza parlour, but why would anyone spend time connecting diamonds and rectangles when they could be making demonstrative code?
In my case it's pieces of A3 paper. I just formally document those designs that are needed to be formally documented and only the parts of those designs that need to be formally documented. These documents are usually associated with a programmers guide and example code.
I've gotten a lot more mileage out of primitive code with meaningful outputs* than I have from tracing my way through a UML tree.
I don't believe either on their own are useful so supply both. As I've said above I don't go for the full formal UML model but use the syntax for some diagrams.
* ie. skeleton code that tells you what it's doing at each step ("I just made BankAccount 'steve'", "fetched 'steve's info", "incremented 'BankAccounts'")
That explains a lot. When you are writing software for real time systems like set top boxes you need to be more formal with your working methods.