|
I am not talking about 'vague requests from management' but about those complex specs that come from organisations like USB, 3GPP, RTCM and so on. Specs where there is too MUCH detail.
|
|
|
|
|
There is no such thing as too much detail. You can't possibly know what someone will be looking for. The real problem is keeping the documentation and its subject in sync, both ways.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Are you completely missing the point of what I wrote on purpose?
|
|
|
|
|
No, not at all. Have you never had the situation that someone else was documenting according to specifications while you were struggling to get the whole thing to work and meet the deadline?
The guy who writes the code does not cut corners because he feels like it. It's the usual case of having something that works reasonably well until the deadline is reached. No time to inform the guy who writes the documentation.
The writer also is busy enough to write down all that stuff in a clear and complete way. He does not want to change too much, as he always got enough left to write about. He just sticks to the specs and probably is not even aware of the changes that have accumulated.
After the deadline both move on to their next assignments and never get the time to clean up. A few versions down the line the documentation will differ from the implementation in many places, but have you ever heard a boss say that the documentation needs to be redone?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
No, and this is a different situation because I am talking about a programmer being either lazy or incapable of understanding a complex specification.
|
|
|
|
|
Yes, but I doubt that in most cases. Most of the time I think it's unintentional and not malice.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Malice?
No, that isnt the definition of malice, this is about a spec being over the top, overkill, and the developer not wanting to understand it.
|
|
|
|
|
Undermining the team's work and its results is not malicious? There has been a time when I did not rip someone's head off when he was not able to complete a job and needed assistance, at least as long as he spoke up. For secretly doing his own thing I would have had him hanging by his (censored).
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
modified 7-Sep-18 6:34am.
|
|
|
|
|
Malice is intentional. If it were he would be sacked immediately!
Stupidity cant be helped though.
|
|
|
|
|
Regarding implementing according to specs: In the 1960s, a Norwegian research institute designed and built by hand a 16-bit minicomputer (years before minis became mainstream). This prototype was then industrialized by two companies: One was a startup with young excited engineers having hear of something called 'documentation' without really knowing the concept.
The other was a 150 year old manufacturing company with well established procedures for all kinds of paperwork. Before production had started, 500 copies of the complete documentation was ready for shipping with the computers. A slight problem was revealed: The guy writing the technical reference manual had misinterpreted the use of the base register (i.e. stack pointer), describing the calculation of the effective address which differed from the prototype (the index register was applied before the base register, opposite of the intended).
Printing 500 reference manuals was expensive in those days. Effective address calculation is so essential that a small errata slip wouldn't do (and would look somewhat unprofessional). Rather than throwing away 500 manuals, they decided to build the machine as documented, rather than like the prototype.
So, in the 1970s, there were two minimachine series from two Norwegian companies with identical instruction sets and addressing modes - except when both base and index registers were involved: Then the effective addess would differ. So they couldn't use each other's binary software. Even though the machines were nearly identical, they ended up taking completely non-overlapping market segments: One was dominating the market for welding machines, huge pen plotters and similar industrial applications; the ohter one took a major share of database applications, office automation etc. Maybe if they had been pefectly identical that the competition would have been negative to both of them. Maybe building according to specs was a good idea after all 
|
|
|
|
|
Spec must be implemented as capable by device. There is no need to implement a set of, for example, response flags that detail the state of the storage memory if the device does not have storage capability in the first place. It's enough just to stick them to the "all fine, nothing to see here" set of values.
The same goes for a lot of seldomly used features, like certain timeouts, watchdogs...
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
AFAIK, a domain-specialist never gets trained in what a spec is; so it must be a developer who writes them.
Munchies_Matt wrote: I think it is because the spec writers want to make it complete, and because of their depth of knowledge, understand what they are thinking.
Where only a developer can be a spec-writer; otherwise you'll get a lot of data and facts that are irrelevant to the project.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
Munchies_Matt wrote: There are not written by developers. Specifications[^]
So you found one exception, and proclaim it the way things work.
Show me a single formal education where you learn wat version-control is and how to write technical and functional specs 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
WTF?
Look, specs like that are not written by developers?
USB spec?
RTCM?
They are written by engineers FFS!
|
|
|
|
|
Munchies_Matt wrote: Look, specs like that are not written by developers?
USB spec?
RTCM?
They are written by engineers FFS!
That's hardware. Most of this site is about software.
And yes, they do come together in a similar way, but that little fact remains - that they are developers. Not writers, not public servants, not linguistic advisors.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Most of this site is about software.
What, CP?
WTF has that got to do with it?
Eddy Vluggen wrote: That's hardware
WTF?
A USB spec has some electrical aspects to it but it is almost entirely about the communication protocol AFTER the line voltage has been negotiated!
As for 3GPP, if you even know what that is, or RTCM, they are radio transmission technologies with complicated functionality.
|
|
|
|
|
Munchies_Matt wrote: WTF has that got to do with it?
Means that if you talk of specs, then software-specs will be assumed, not hardware.
Munchies_Matt wrote: A USB spec has some electrical aspects to it but it is almost entirely about the communication protocol AFTER the line voltage has been negotiated!
Software; again, done by developers based on the interface that the hardware-engineers supply.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
You arent defining firmware as hardware are you?
|
|
|
|
|
Who needs specs in an agile environment?
Let's just start with 'int main(int argc, char **argv)' and take it from there as we learn what is needed. We can code it immediately, and the code will show how to solve the problem. Code will never be out of sync with the spec, because the code is the spec.
As long as you use reasonable variable and function names, you don't even need comments. Out-of-date comments are even more misleading than out-of-date specs, because you trust them much more, being so close to the code. We all know that documentation is unreliable and should never be trusted.
The only thing that matters is what is written down as code. The code is the terrain. Design, specs, comments or any other sort of writing are just poor maps of the terrain. Get yourself out in the terrain to see what it is really like. Be agile!
|
|
|
|
|
I thought you were joking for a moment.
OK, when you grow up and write some real software you will know what I mean.
|
|
|
|
|
I did my first programnming assignments at the University on 80 column punch cards.
|
|
|
|
|
SO if you have been in the game so long why havent you ever had to work with a big complex spec, something like USB for example, or the GSM spec?
|
|
|
|
|
I am very happy with good specs; I have read thousands of pages of ISO and ITU standards, some of which are excellently written. Especially for interface/protocol specs, I am very fond of specs based on state machines - they tend to make the spec terse, complete and unambiguous. (If you would like an example, pick up X.225, the OSI protocol stack Session layer - it is outdated now, but could serve as schoolbook example of a FSM based protocol spec.)
If you are still in doubt: In my first post in this thread, I was most certainly joking. Except that I think it is no laughing matter, it is rather sad how little the young crop of "agile" developers value specs, good designs and thorough problem analysis. It most certainly reduces the quality of the software we produce nowadays.
If you want well designed, robust software today, do not try to find it among those agile software broilers pouring out from the universities. Seach for those who know the problem domain. If you want a sound editor, search for studio people. Do you need document creation software, go to the publisihng business. Do you need software to keep track of your dog breeding, go to the farmers' organizations. Do you need a programmer's workbench, go to the open source community, that they know well and produce high quality software for. But not for movie editing, dog breeding, office automation or map construction.
For many youngsters today, agile makes you specless. You are free to take whatever next step you want, without asking anybody without telling anybody.
Agile doesn't have to be that way. But quite often, that's the way it turns out. Writing down anything else than code is something your boss forces you to (if he does!), and you do it after completing the code; you do not preapre and use it as an aid in the implementation phase. If you suggest anything in that direction, everybody under thirty (and a fair share of the older ones) give you that ugly look and snare "Waterfall!" at you.
|
|
|
|
|
Sarcasm never comes over well in text. 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
