Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

‘Laws’ of Software Development

exceptionnotfound.net

Post reply on HN
Print view View original

51–60 of 74 posts

Re: ‘Laws’ of Software Development

#51

Post by munificent »

lukasm wrote: post #48

Atwood: "Any application that can be written in JavaScript will eventually be written in JavaScript" Zawinski: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." s/mial/API etc And I can't find this one (IBM study?) "Adding 10% of features increases cost by 100%"

> Adding 10% of features increases cost by 100%

Too bad the inverse isn't true. Would be nice if we could cut costs by 100% just by ditching a tenth of the features.

Re: ‘Laws’ of Software Development

#52

Post by mjevans »

recursive wrote: post #41
a3n wrote: post #34

Earlier quoted context omitted.

CRUD

I've worked on CRUD apps for my whole career, and I've never seen one that didn't have some novel requirements.

Even when you're using some base that already exists (often a highly configurable thing that's been sold to you by someone else), you STILL have the frequent stories of nightmares involving either an inability to configure it to the desired specification or cost and time overruns of epic proportions.

Re: ‘Laws’ of Software Development

#53

Post by Gibbon1 »

VMG wrote: post #20

Careful with Postel's Law: it brought us a lot the mess we have with web standards. Quoting wikipedia https://en.wikipedia.org/wiki/Robustness_principle : > In RFC 3117, Marshall Rose characterized several deployment problems when applying Postel's principle in the design of a new application protocol.[3] For example, a defective implementation that sends non-conforming messages might be used only with implementation…

I think it's okay when dealing with input from hairless monkeys. That people just aren't particularly consistent is part of the problem domain.

Not so okay when dealing with input created by programs.

And as you said totally not okay when dealing with protocols, encryption, and authentication. See padding attacks.

Re: ‘Laws’ of Software Development

#54

Post by composer »

ReRe's Law of Repetition and Redundancy

A programmer can accurately estimate the schedule only for the repeated and the redundant. Yet,

A programmer's job is to automate the repeated and the redundant. Thus,

A programmer delivering to an estimated or predictable schedule is...

Not doing their job (or is redundant).

Re: ‘Laws’ of Software Development

#55

Post by steveoc64 »

The DateField hypothesis :

For any given reasonable estimate for an item of software, add 2^N days to that estimate, where N = the number of date/datetime fields involved on that form or database table.

eg - You have a complex data entry screen to add to a webpage, and you KNOW for certain that you can complete it thoroughly in 2-3 days tops, testing every possible edge case. Good stuff.

However, if that screen has 2 date fields involved, then its going to take 2^2 or 4 extra days over and above the reasonable estimate to get it done properly, and handle NULL dates, timezone differences, comparison of dates for equality, parsing date inputs, converting internal representations between front end / backend / storage ... and every other unexpected abomination.

Re: ‘Laws’ of Software Development

#58

Post by steveoc64 »

Retra wrote: post #57
riazrizvi wrote: post #46

~~laws~~ rules of thumb

A "law", in the scientific sense, is really just a detailed observation.

Good point.

Note also that some "laws" may remain as "laws", even in the face of experimental evidence which directly contradicts the predicted results of that law.

Which gives rise to "The Law of Research Funding", in which the amount of funding that can be attracted to support a given law is proportional to the amount of real world experimental evidence which contradicts that law. :)

Re: ‘Laws’ of Software Development

#60

Post by rhizome »

munificent wrote: post #51
lukasm wrote: post #48

Atwood: "Any application that can be written in JavaScript will eventually be written in JavaScript" Zawinski: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." s/mial/API etc And I can't find this one (IBM study?) "Adding 10% of features increases cost by 100%"

> Adding 10% of features increases cost by 100% Too bad the inverse isn't true. Would be nice if we could cut costs by 100% just by ditching a tenth of the features.

The inverse gets you bumping up against Pareto, though, so...pretty close.
Post reply on HN