Slashdotista: Fundamental coding truths

Tietokonejutut, pelit ja muu nörtismi; autot, kaasupullot ja muut lelut
huima

Slashdotista: Fundamental coding truths

Viesti Kirjoittaja huima »

http://ask.slashdot.org/comments.pl?sid ... d=14049115

by WiMoose (863260) on Wednesday November 16, @08:56PM (#14049115)

In addition to some of the suggestions made so far I would add a good automatic regression-test system which runs every night, and reports problems (build failures or result diffs). I've made mine so they "find the guilty" (whoever committed code since the last good regresstion test).

I recently put together a list of Fundamental Coding Truths after musing about this topic and why it was so hard to plan software development:

1. Software is not at its core a collection of a few clever algorithms.
Rather, it is primarily (in the ways that matter) a huge collection of arbitrary choices and random implementation details.

The algorithms that consititute the mathematical/logical basis of a piece of software are an important, but very small (eg: 1%) and relatively very simple part of the overall code.

2. Code complexity is pretty much exclusively determined by the (combinatorial) number of interactions between pieces. Each interaction requires at least one decision and usually many more.

3. Because of #1 and #2, deep, intimate familiarity with the code (this vast collection of implementation details) is only ever fully knowable to the original author(s) who made these uncountably many, mostly arbitrary decisions.
(Familiarity by secondary authors/maintainers comes primarily from
re-writting sections of code.)

4. Because of #3, programmers are not interchangeable. The efficiency with which a person can navigate the code, implement or even imagine changes is almost entirely determined by how familiar they are with these many, many small details. The ratio of efficiencies between a primary author and another equally talented coder is very large (eg: 100). Because of this, the original authors of a section of code are usually the only ones who are ever able to efficiently modify or restructure it. This becomes rapidly more true as the the size and complexity of the code increases.

5. Because of the complexity of code (the number of interactions and interdependencies), debugging and maintenance constitutes the vast majority (eg: 99.9%) of the work required by a piece of software over its life.

6. Because of the complexity of code (number of interactions between components), it is very hard, if not impossible, to predict with any accuracy what will be involved in implementing a given change. Even for original authors, unintented side effects are almost inevitable, and the primary determinant of the length and difficulty of a task lies in finding and rectifying
unintented consequences or unforseen interactions. Because of this, the uncertainty in the time it will take to execute a change is very large.
(eg: 10x range in 95% confidence limit of time estimate, say 1 day-2weeks).

7. Because of the complexity of code, bugs are an inevitable byproduct of writing code. It is hard to predict how long it will take to find and repair bugs as that depends on how many side effects are involved, which is not known until the repair is done and "fully tested". The only way to avoid bugs completely is to not write code. There are things that can minimize bugs or speed up finding/fixing them, but they will always exist.


Ja siksi, Gattaca, ne yberkoodaajat ovat sen palkkansa arvoisia.
Avatar
aasi
Kitisijä
Viestit: 6685
Liittynyt: 01.07.2005 21:12
Paikkakunta: Uleåborg

Re: Slashdotista: Fundamental coding truths

Viesti Kirjoittaja aasi »

huima kirjoitti:In addition to some of the suggestions made so far I would add a good automatic regression-test system which runs every night, and reports problems (build failures or result diffs). I've made mine so they "find the guilty" (whoever committed code since the last good regresstion test).
Juuri tänään totesin hajonnutta systeemiä ihmetellessämme että siinä käytetyt testit pitäisi ajaa säännöllisesti automaattisesti. Testiympäristö oli vain jotenkin hajonnut kahden kuukauden aikana sitten viimeisen tuotantoon siirron, eikä hajuakaan milloin, miksi ja miten tuo oli tapahtunut. Mitään kehitystä kun ei tuona aika oltu tehty, nytkin olisi tarvittu vain bugikorjaukseen.

Tämän phpBB-foorumisoftan koodi on muuten erittäin hyvä esimerkki hankalasti muokattavasta. Tämä viewtopic.php sisältää esimerkiksi 1500 riviä koodia ja nelisenkymmentä globaalia muuttujaa. Ei oikein oma muisti enää tahdo riittää suorituksen hahmottamiseen. Sääli että pilkkomalla hahmotettavampiin paloihin menettäisi vain samalla helpot päivitykset ja valmiit lisäpalikat.
Tasan ei mene muumit kanootissa.
Vastaa Viestiin