[Oberon] FPGA - OberonV4 Dialogs

Chris Burrows chris at cfbsoftware.com
Sun Dec 16 00:28:47 CET 2018

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Andreas Pirklbauer
> Sent: Sunday, 16 December 2018 4:22 AM
> To: ETH Oberon and related systems
> Subject: [Oberon] FPGA - OberonV4 Dialogs
>     > However, I think that this would be a step backwards. But it
> may be justified if a large
>     > body of Oberon-2 code exists, which would take too much time
> and effort to adapt..
>     >
>   >I would say yes. Just look at the Linz libraries with all the
> network software. It will b
>   > lots of unnecessary work to port all this SW to a slightly
> different language variant.
> By looking at the differences, I estimate it would be a few days of
> work excluding testing (for someone familiar with the compiler). Now
> we just need a volunteer  ;-)

At the risk of being a 'wet blanket' ...

An estimate 'excluding testing' can lead to false expectations. Optimistic estimations are a common failing of software developers. Just like gamblers they only remember past wins and conveniently forget about the losses. One statement I hear all the time is 'I've just got one more bug to fix and then it will be finished'.

Typical programming tasks take 10% of the time to get 90% done but 90% of the time to get the remaining 10% done.

To account for these factors, a good rule of thumb to arrive at reliable estimates is to breakdown the development of software to 40% design, 10% coding and 50% testing / debugging. 

In this case, assuming 'a few days of work' means 'five days' (i.e. more than a couple of days but less than several days), and the number of man-hours per day is eight, that would mean that it would take 40 man-hours to get it to a state where it compiled without errors and survived minimal tests. 

However, following the rule of thumb, an additional 200 man-hours would then be required to make sure that it works correctly for all scenarios. If a volunteer has done the first (fun) part, it would be prudent to assume that the end-user would be liable for this second (tedious) part,

Chris Burrows
CFB Software


More information about the Oberon mailing list