Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
6 hours ago, Fulcrum.013 said:But specs it is not a process description. It is a start point of researching project field common rules. And it is responcebility of developer to find ranges in wich specs may be adjusted by data driven way before begin any coding.
5
Specs absolutely can be a process description. I'm starting to seriously doubt you've ever worked as a developer in a professional capacity.
35 minutes ago, mr_tawan said:Spec is the alpha (the starting point) and the omega (the end results) in classics software development process.
Specs is a startin point of research. Or better say it is a target of researches. But specs can not be used to design a software architecture, becouse it is just a list of features without any explanation how it have to work inside or even detailed description how it have look. Only universal process rules that determined by developers during analise of task field can be used to software architecture design and then implementation. And only this way allow to meet any specs and flexible reflect any specs changes. Becouse specs may be changed or extended, but process rules still constant, becouse mathematical background of any process is constant.. It is how any engineering including software engineering works. And it what eny univesity prodessor teach his students.
1 hour ago, ChaosEngine said:I'm starting to seriously doubt you've ever worked as a developer in a professional capacity.
Companies that developt serious software directly state into their internal rules that at least 2/3 of working hours software engineer have to analize a task field and design architecture and no more then 1/3 of working hours works with code implementation and debuging. Really idea that to architect and implement software that have to control sets of 10megawatt motors can beenought a 1-2 pages of paper at least 50% of wich list a requrements to system stability and allowed downtimes and other 50% is list of requirements to final product dimensions tolerance can be enought docs even not looks like a joke. It looks as complete incompetence in software development field, or better say even a complete absent of undertanding of term "algorithm"
2 hours ago, ChaosEngine said:Specs absolutely can be a process description.
Just a real story. One sunny day, 20 years ago, director of IT departament of 40k-employes machinery buildung factory, where i has work as senior developer, has grate to a meeting all developers that has lead design or designed himself factory-wide IT systems, that works into production, and say that company general director give a new task to IT departament that figured out by a tiny specs: "Director have to press a button and computer have to show reports how many loses and profits factory have today, from witch it come and exactly recomendations how to avoid losses and increase profits."
Is you really think its specs enought to make system like it without any researches?
49 minutes ago, Fulcrum.013 said:Is you really think its specs enought to make system like it without any researches?
We do research, and then update the spec with the outcome from the research. After that we do the code, and then update the spec as there might be updates along the way.
Of course the process differs from company to companies.
3 hours ago, ChaosEngine said:Specs absolutely can be a process description. I'm starting to seriously doubt you've ever worked as a developer in a professional capacity.
I have the same feeling....
Here is my story, my company has ~15k employees across 6 countries around the world (another hint: it has been just purchased by another company recently). Myself, as a middle level programmer was assigned to implement a functionality for FATCA project (which I believe it's familiar for all US citizen :)). We start with a requirement document made by a business analyst (who's belong to BA team). After BA complete his document, it was distributed to every people in the project team (which includes project manager, 2 programmers, a tester). Myself and another programmer will then read the document and come up with a document that our company calls 'Enhancement Specification'. This document contains both detailed business needs, technical specs, and testing which is at this point left blank.
After that, we implement each own module. I'm on the C++ frontend, and she's on the database backend. There were some details that we hadn't thought about before, they were add to the document at this point. We work on them until we satisfy with the change, and then we deliver it at the milestone date. Concurrently, the tester work on the test scenario part of this
After that, the tester would work on her test. The tester found something that we have never thought of before (again), so we discussed with her and the BA and update the spec to match the outcome of that discussion. We continue to work on this until the tester said "OK", which I think it's on the forth variance of that release.
And then later on, the release went to the UAT stage. At this point another set of tester which this time are representative of the actual users would work on this functionality. They don't test the functionality point-by-point, rather they come up with scenario that more resemble the real world usage (hence user-acceptance test). At this point there were no major changes. However if there're needs to do so then we have to get back to the spec and update it. Also if there's fix/changes, it goes back to the first tester (QA) to to the functional testing first before it goes back to UAT. Only after UAT without any major issue then it goes to production, which happened to be our case here. If the UAT fails, the functionality will be removed.
As you can see, through out the project, the specification gets update along the way. It's been through at least a dozen of revision and was touched by handful of people.
PS. I have to hide some details as I might get sued... A few years after this project, I moved on to another department which has entirely different process.
53 minutes ago, mr_tawan said:and then update the spec with the outcome from the research
May be we mean something differend under specs terms, but here it mean "list of requirements that system have to meet".
For example one of stability-requirments: system have to be able work without software, malfunctions reboots and maintence at least 10k hours. sheduled maintenxe downtimw have not exids 2 hours. In case of malfunction repairments downtime must not exids 45 minutes. Time to switch control lines to stand-by control system have not exids 2 minutes.
Other requirements equipment related: rolling mill forces have not exids Fmax meganewtons. Torque of main engine have not exids Tmax H*m. Current of main engine must not exids Amax ampers. etc.
Other requirments final production tolerance related: system must be able to produce 8 - 60mm sheets with 0.1mm tolerance. Temperature tolerance before first and after last milling pass must not exids 5С from values given by steel testing laboratory for processed kind of steel.
And anything of it is not subject of change or even dispute, becouse come from equipment abilities and requirements for final production quality, so violation of it will affect product quality or cause serious equipment damages anf personel injurities.
Other minor requrements of cource may be changed. For example requirment "rollgangs motors not involved into work have to be switched to stand-by mode" may be changed to "have to be turned of" and vice verse. but changes like it very easy to implement by data-driven way.
But those requirments is not describe how system have to be sedigned or even on wich principles it have to work to meet it. It just a source for creation of big book called a "task description" that consists of parts like "mathematical description" that exactly describe any involved mathematical methods and relations betwin them, "information description" that complete describe data formats, network protocols, placement of control terminals and roles of ppersonel that interact with a system, and so on, "measurment tools description" that describes a involved sensors and requirments when and how to make mesuarments and so on (really it is a big stand of books) . And only when it document complete ready it have sence to start a design of software architecture. Just becouse anything of it required to core system functionality such as computing of rolling schema. Also anything of it can not be changed even litlle bit until customer purchase new rolling mill and can not be significant changed until god issue new Newton, Young, Ohm and other physical laws. So it have no any sence to split analize to iterations, especiall becouse it is not a option to make a partial functionality and especially partial stability or partial bug-free prototype into this case. Also whole system description allows to determine a similar functionality and make any functionality only once (main head pain of iterative is doubling of same functionality). Of course implementation using split by modules that firstly using data stubs to debug it, then connected to data that comes from other modules after it implemented. But removing of stubs is not a iterations. Other modules implementation can be done parallely by bigest team, but usualy teams is not so big becouse task is higly complexive and entry time is very big, and code implementation can use a common components that after data-driven adjustments can be used into any input signal processing and output signal generation purposes. Also it is plenty of same complexiti tasks on other production zones of same plants each of wich have to have his own automation system that control his own different process. So SCRUM/AGILE and other "write prototype without detailed analize" metodologies just never will work for complexive software.
Same into bussines accounting software - than deeper and you "drill" field in whole task scale than simpliest ways of solution you have. Even in case govermet issued lows changes little bit frequently then god issued. I has not so big expirience into accounting software becouse has shifted to FA field just after graduated from university. Just for example when i has been a 15 years shcoolboy a has designed a sowtware thet school administration used to compute teachers salary. by first look to specs given by accountant it realy huge task. it have at least 3 pages list of kinds of accurals and deduction. so i has start to research how to compute it. after a half of hour talks with accountant i has clear that it is only 3 algo of accurals - working hours based, work quantity done based and percentage of average previouse month salary based, and 3 algo of deductions - fixed amount, fixed percent and progressive percent. So shortly i has implemented and testsed 6 tiny subroutines for each case, table that consists of codes names algo id and actual taxes and main routine that has collect input data by table, call required algo, collect and sum results and finally print out a hard copy of receipt. Unfortunately school have only some soviet clones of PDP-11 at this time, with only working remote 360KB floppy drive for 13 machines, so it has been no any chance to involve database or even file storage to store constant employes and lookup table data, so accounter have to enter same data each month and kinds lookup table has been organized as a constant array into source code, but it allow to speed up work of accounter at least 10 times and still have easy adjustments to salary lows changes. Of cource not all into accounting and bussines software such easy, but this story show a key difference betwin designing software iteratively based on customer specs and designin on task description based on complete field analises that done by developer with involving of task field professional.
1 hour ago, Fulcrum.013 said:And anything of it is not subject of change or even dispute, becouse come from equipment abilities and requirements for final production quality, so violation of it will affect product quality or cause serious equipment damages anf personel injurities.
This part doesn't apply to video games. We aren't going to kill anyone or damage a factory robot or blow up a rocket if we screw up. Our requirements aren't based in physical reality, but rules made up by game designers.
1 hour ago, Fulcrum.013 said:But those requirments is not describe how system have to be sedigned or even on wich principles it have to work to meet it. It just a source for creation of big book called a "task description" that consists of parts like "mathematical description" that exactly describe any involved mathematical methods and relations betwin them, "information description" that complete describe data formats, network protocols, placement of control terminals and roles of ppersonel that interact with a system, and so on, "measurment tools description" that describes a involved sensors and requirments when and how to make mesuarments and so on (really it is a big stand of books) .
This kind of thing simply is not used in the game industry. We're usually under too much time pressure to bother with this kind of thing and we would just end up rewriting it every other day even if we had it. A big design document like this would be out of date within a week of starting to implement it! Oftentimes what designers initially think is going to be fun, turns out not to be when they actually get to playing the game (so there's a spec rewrite...) or the engineers find that the way they were going to write the code doesn't actually do what the designer was looking for (so they would have to rewrite the task descriptions).
1 hour ago, Fulcrum.013 said:Also anything of it can not be changed even litlle bit until customer purchase new rolling mill and can not be significant changed until god issue new Newton, Young, Ohm and other physical laws.
This also doesn't apply to video games. We aren't constrainted by Newton, Einstein, et. al. and their laws. Our "physical laws" are rules made up by game designers to make a fun game.They often make up new ones at the most random of moments. In fact, most of the time game designers don't even want something that is truly "real", as in modelling how physical reality actually works. They want something that is fun, not something that is real. A game I worked on recently featured balls that would bounce off the edges of the screen - and unlike in the real world, bouncing off the edges would make them speed up! Not particularly realistic, but very satisfying to watch. 
I also was working with a designer who wanted something that would apply a force to objects that went past the thing - but it would apply more force to only some of them (without changing their physical parameters in any way), because doing it in a physically realistic way resulted in a game that wasn't understandable to the player.
In real life, you can't go faster than light - but in a video game, I could make a submarine that goes faster than light. I could make a game where everything moves instantaneously from one place to another and then stops immediately when you apply a force to it. 
In a video game, reality is a toy.
Thank you for posting your perspective. I get the impression that you have a lot of experience in control software. Now, please consider our perspective. I appreciate that what you're saying here may well apply to software that controls real, physical hardware - unfortunately I can't comment on that, because I have no experience writing that kind of software at this time - but the limitations on that kind of software simply do not apply to video games. I suggest that this difference in perspective is the cause of your disconnect with us in this thread.
You need to imagine a world where all the physical rules are made up by humans and humans can change those rules at any time.
I just want to say that this discussion is not about real physics or not. For example collsion need to be precise in both cases. Also games caused deaths in the past. In that ueber vehicle the specs for the sensors produced a working product. But they seem to use agile for the classification of the objects the sensors detect. Sometimes I have long time spans where I work to specs. Then feel guilty that I do not delegate this stuff off shore.
2 hours ago, Oberon_Command said:This part doesn't apply to video games. We aren't going to kill anyone or damage a factory robot or blow up a rocket if we screw up. Our requirements aren't based in physical reality, but rules made up by game designers.
Of course gaming is a zero responsivity software. But in case AI autopailot will significant violate similar constarints of speed, turn factor, etc your game designer will be hevily morally indgured that can cause significant damadge to his keyboard and monitor, and other phisicaly realistic hurricane effects over heads of programmers.
2 hours ago, Oberon_Command said:Our "physical laws" are rules made up by game designers to make a fun game.
Practicle show that then close game to real phisics and then more it utilize a real robotics algos than easier it can be implemented and tweaked and have more funny gameplay. Of course it is no restrictions to change gravity direction or make vine from a water. But changing of gravity not affect a core of Newton laws and again have to be made by data-driven way. Even in case you will invent a new sinusoidal force that affect spherical horses into relativistic vacuum it will be applied to such horses by common low of forces and toqcues addition so affects only it force computation but not a core of simulation. So proper decomposition will save any gaming world from overtimes.Really even 20-year old engines have anything of it adgustable into level editor. So in case you see kilometers of harcoded trajectories, etc into old bools-made games source, be sure that it code is machine generated by visualy edited data, just to slightly increase perfomance.
3 hours ago, Oberon_Command said:Oftentimes what designers initially think is going to be fun, turns out not to be when they actually get to playing the game
Looks like you to much love to work hard like as computer.I am instead very lazzy. Even so lazzy so dont want to make work, that i can easily teach a computer, myself.
3 hours ago, Oberon_Command said:A game I worked on recently featured balls that would bounce off the edges of the screen - and unlike in the real world, bouncing off the edges would make them speed up! Not particularly realistic, but very satisfying to watch
Just set a bumpy factor >1 for eggs matherial into real phisic simulation engine and you will have same effect. Just change only numver and make your designer fantastic happy without a line of code.
