This code has no value
"This [any] code has no value"
Since I've been encountering the games world and how they deal with software this is a term I've heard a few times, along with "Oh the tech is always messy, it's just the way it always is". It's rare you see such a good example of "truth by constant assertion" or a system that is in a race to the bottom.
Opposed to answering a claim that is little more than an excuse not do to a decent job, it's likely better to figure out what is the "value" that is being talked about as there are a few kinds.
Firstly there is the cost of the end product, how many hours at what salary rate etc, plus over heads and what ever added and draining costs unnecessary suits are going to add. That at least will give you a raw currency cost. Misleading most of the time I've found (i.e. oh it's expensive, it must be good), though some what necessary in the world of commerce.
Once there is a product, there is the value to the company of what can be done with it. Can it be licensed and re-sold, used internally, white labelled etc. Though this within itself is dependant of the main thing that will bring down nearly all forms of value, Technical Debt.
One of the comments I hear that made me think about this post was leaving a company with another developer and he said "Oh they'll be pulling teeth for months, the code has no value without the developer who wrote it".
I instantly thought : Typically not, good software is build with the design, layout, architecture, comments all rolled in and part of the whole process. Otherwise all you're getting is the last 10% of the work, the implementation once all the logic has been thought out choices made.
A developer is paid for 100% of their time and then project (you'd hope !) ..... so why is the company only after, or thinks it only needs the 10% ?
Impatient, naive and poor management is the usual answer I've found.
I've had a few experiences where software people are treated as workers on a production line and you just throw more of them on, or "make" them work faster to get more output. Now given that most places fall into that counter productive mind set and treat the process of creation like Victorian work farms, I can see the logical next step that what ever "comes out the end" is what you want.
This is also reinforced by middle management "producers" and the like, who believe they are actually the ones making the choices on how the work is built. Funny and shocking I know.
An aside ........ though a good segue into what I think has value and how the value can be keep in the project separate from the developers, though obviously heightened with them about.
Given that any piece a substantial code will pass though a few if not many hands in its life, and it's only ever "done" when it's never worked on again, lots of people are going to have to read though, modify and most importantly understand it.
The thinking that went into the creation and the way the logic was solved is what has the most value, what language your using doesn't have that much impact (part of what irks me when people become evangelical about their tech over any other, i.e. the Ruby or Druapl mobs). Communicating why something was done and a brief explanation of how will reduce the learning curve of the next worker dramatically.
And what are the two main things that typically poor management do to projects ? Demand that coders start work instantly "what's what we pay them for" ..... i.e. usurping design. Then making up arbitrary time lines which make the developers curtail efforts and compress the working style into :
// Does things
$storeforrandomtime = $foo->bar($t)->hammersmith($e) * $varfromthreefilesago;
I've been on projects looking at code worse than that sat next to the "manager" who paid for it explaining that it was going to take a few months to clean up to be workable with, the only reply I had was "Yes, weeks right, don't say months" ......... sufficed to say I left that chaos pit!
So what would make it all different ?
Firstly, a recent project I'm working on has a strange thing called design ! The data layer is designed, the business logic, all the APIs and data flows are done. The whole thing presents itself transparently, you can see near instantly where everything is, and more importantly why. The choices and ideas of development are communicated. It could be in PHP, Java, Erlang, but the essence of the project is there.
It's only the very junior developers and armature management that accept anything else as a job done well.
It's more a case of capturing why not what, and during the design phase as well, not the implementation phase. Another reason why non-engineering "management" should stay away from the wonder drug that is "agile" development ...... lack of understanding and ability to gauge impact on architecture.
Misuses of agile has given way to the same symptoms as the greed prevalent in the financial systems of the world ...... short term gains and sly deals at the expense of anything sustainable and on going.
Secondly make sure the ideas and creation steps are seen for what they are, opposed to being done during the same time as implementation (and I don't mean prototyping).
Third, have a think about what it is you're actually paying people for ........ are they making widgets or using skills and experience to make decisions, that need to be recorded.
It goes beyond "Oh just comment the code" ........ though for some that would be a good start.
@JeremyHutchings
Since I've been encountering the games world and how they deal with software this is a term I've heard a few times, along with "Oh the tech is always messy, it's just the way it always is". It's rare you see such a good example of "truth by constant assertion" or a system that is in a race to the bottom.
Opposed to answering a claim that is little more than an excuse not do to a decent job, it's likely better to figure out what is the "value" that is being talked about as there are a few kinds.
Firstly there is the cost of the end product, how many hours at what salary rate etc, plus over heads and what ever added and draining costs unnecessary suits are going to add. That at least will give you a raw currency cost. Misleading most of the time I've found (i.e. oh it's expensive, it must be good), though some what necessary in the world of commerce.
Once there is a product, there is the value to the company of what can be done with it. Can it be licensed and re-sold, used internally, white labelled etc. Though this within itself is dependant of the main thing that will bring down nearly all forms of value, Technical Debt.
One of the comments I hear that made me think about this post was leaving a company with another developer and he said "Oh they'll be pulling teeth for months, the code has no value without the developer who wrote it".
I instantly thought : Typically not, good software is build with the design, layout, architecture, comments all rolled in and part of the whole process. Otherwise all you're getting is the last 10% of the work, the implementation once all the logic has been thought out choices made.
A developer is paid for 100% of their time and then project (you'd hope !) ..... so why is the company only after, or thinks it only needs the 10% ?
Impatient, naive and poor management is the usual answer I've found.
I've had a few experiences where software people are treated as workers on a production line and you just throw more of them on, or "make" them work faster to get more output. Now given that most places fall into that counter productive mind set and treat the process of creation like Victorian work farms, I can see the logical next step that what ever "comes out the end" is what you want.
This is also reinforced by middle management "producers" and the like, who believe they are actually the ones making the choices on how the work is built. Funny and shocking I know.
An aside ........ though a good segue into what I think has value and how the value can be keep in the project separate from the developers, though obviously heightened with them about.
Given that any piece a substantial code will pass though a few if not many hands in its life, and it's only ever "done" when it's never worked on again, lots of people are going to have to read though, modify and most importantly understand it.
The thinking that went into the creation and the way the logic was solved is what has the most value, what language your using doesn't have that much impact (part of what irks me when people become evangelical about their tech over any other, i.e. the Ruby or Druapl mobs). Communicating why something was done and a brief explanation of how will reduce the learning curve of the next worker dramatically.
And what are the two main things that typically poor management do to projects ? Demand that coders start work instantly "what's what we pay them for" ..... i.e. usurping design. Then making up arbitrary time lines which make the developers curtail efforts and compress the working style into :
// Does things
$storeforrandomtime = $foo->bar($t)->hammersmith($e) * $varfromthreefilesago;
I've been on projects looking at code worse than that sat next to the "manager" who paid for it explaining that it was going to take a few months to clean up to be workable with, the only reply I had was "Yes, weeks right, don't say months" ......... sufficed to say I left that chaos pit!
So what would make it all different ?
Firstly, a recent project I'm working on has a strange thing called design ! The data layer is designed, the business logic, all the APIs and data flows are done. The whole thing presents itself transparently, you can see near instantly where everything is, and more importantly why. The choices and ideas of development are communicated. It could be in PHP, Java, Erlang, but the essence of the project is there.
It's only the very junior developers and armature management that accept anything else as a job done well.
It's more a case of capturing why not what, and during the design phase as well, not the implementation phase. Another reason why non-engineering "management" should stay away from the wonder drug that is "agile" development ...... lack of understanding and ability to gauge impact on architecture.
Misuses of agile has given way to the same symptoms as the greed prevalent in the financial systems of the world ...... short term gains and sly deals at the expense of anything sustainable and on going.
Secondly make sure the ideas and creation steps are seen for what they are, opposed to being done during the same time as implementation (and I don't mean prototyping).
Third, have a think about what it is you're actually paying people for ........ are they making widgets or using skills and experience to make decisions, that need to be recorded.
It goes beyond "Oh just comment the code" ........ though for some that would be a good start.
@JeremyHutchings
Comments
Post a Comment