Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««34567»»»

It Happens Expand / Collapse
Author
Message
Posted Wednesday, September 25, 2013 11:57 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, June 25, 2014 7:33 AM
Points: 27, Visits: 101
Gary Varga (9/25/2013)
simon.crick (9/25/2013)
...This is 100% truthfull, and I do not like the suggestions that I am lying.


I for one am not suggesting that you are lying but how can any system, regardless of complexity, not require enhancing to comply with new regulation that was not on the statute books (if in UK - may be another term if in a different country) at the time of development?

I find that an amazing feat!!!

Eager to learn so please share.


It is a client database and commission tracking system. It is used to keep track of the pensions, investments and other financial products held by approx 1000 clients, as well as automatically track commission payments from the financial institutions (e.g. pension providers) to the advisor and from the advisor to the agents that introduced the clients. Many new types of financial products have emerged over the last 20 years, but the database schema has been generic enough to cope.

To satisfy the regulations that you mention, I believe the advisor has to keep scanned copies of policy documents and authorisation instructions, etc, but these are not stored in the client database.

As I mentioned earlier, there were several off-the-shelf packages available at the time, but they were all way to complicated and did not have the flexibility to cope with future changes.

The system we created was much simpler and much more flexible. It satisfied the requirements without imposing any unnecessary constraints, and it has stood the test of time.

Simon


Post #1498523
Posted Wednesday, September 25, 2013 12:04 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:45 AM
Points: 5,813, Visits: 3,734
simon.crick (9/25/2013)
Gary Varga (9/25/2013)
simon.crick (9/25/2013)
...This is 100% truthfull, and I do not like the suggestions that I am lying.


I for one am not suggesting that you are lying but how can any system, regardless of complexity, not require enhancing to comply with new regulation that was not on the statute books (if in UK - may be another term if in a different country) at the time of development?

I find that an amazing feat!!!

Eager to learn so please share.


It is a client database and commission tracking system. It is used to keep track of the pensions, investments and other financial products held by approx 1000 clients, as well as automatically track commission payments from the financial institutions (e.g. pension providers) to the advisor and from the advisor to the agents that introduced the clients. Many new types of financial products have emerged over the last 20 years, but the database schema has been generic enough to cope.

To satisfy the regulations that you mention, I believe the advisor has to keep scanned copies of policy documents and authorisation instructions, etc, but these are not stored in the client database.

As I mentioned earlier, there were several off-the-shelf packages available at the time, but they were all way to complicated and did not have the flexibility to cope with future changes.

The system we created was much simpler and much more flexible. It satisfied the requirements without imposing any unnecessary constraints, and it has stood the test of time.

Simon




Sounds reasonable. I wouldn't describe it as complex myself but that is a subjective term.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1498525
Posted Wednesday, September 25, 2013 12:23 PM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Yesterday @ 12:04 PM
Points: 705, Visits: 1,779
I wouldn't describe it as complex myself but that is a subjective term.


It's an n=2 problem. Simon has a right to be proud, but not judgmental. Many of us are dealing with n greater than 2 problems.

I doubt his software deals with census demographics, address certification, geocoding, web interfaces, new operating systems, embedded scripting languages and a insanely large number of disparate data formats.

I envy him.
Post #1498533
Posted Thursday, September 26, 2013 12:38 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, June 25, 2014 7:33 AM
Points: 27, Visits: 101
chrisn-585491 (9/25/2013)
I wouldn't describe it as complex myself but that is a subjective term.


It's an n=2 problem. Simon has a right to be proud, but not judgmental. Many of us are dealing with n greater than 2 problems.

I doubt his software deals with census demographics, address certification, geocoding, web interfaces, new operating systems, embedded scripting languages and a insanely large number of disparate data formats.

I envy him.


I'm not being judgemental, I just think that the software industry is way behind almost every other industry in terms of quality control, and I think we should be aiming much higher than just "mostly bug-free code".

Would you accept a "mostly fault free" product from any other sector, e.g. a mostly fault free car?

Part of the problem is that many software companies start selling new products before the code is even written. They promise to deliver in unreallistic timescales, and we (the engineers) then have to rush our work, resulting in low quality products.

I'm not sure what the solution is, but to "embrace the idea that code can be wrong" (Nathan Marz) seems like the wrong approach to me. I think we should be aiming to release 100% bug-free code. Requirements may change over time, but we shouldn't be knowingly selling code that contains bugs.

To get past this, I believe we need a culture shift. Way too many people in the software industry think it is normal and acceptable to release products that contain bugs. This is basically fraud, and would not be tolerated in any other industry.

Post #1498680
Posted Thursday, September 26, 2013 1:18 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, June 25, 2014 7:33 AM
Points: 27, Visits: 101
chrisn-585491 (9/25/2013)
I wouldn't describe it as complex myself but that is a subjective term.


It's an n=2 problem. Simon has a right to be proud, but not judgmental. Many of us are dealing with n greater than 2 problems.

I doubt his software deals with census demographics, address certification, geocoding, web interfaces, new operating systems, embedded scripting languages and a insanely large number of disparate data formats.

I envy him.


Actually, I now work in the GPS tracking and fleet management industry, and our software does deal with address resolution, geocoding, web interfaces, new operating systems (hundreds of servers, thousands of client workstations, tablets, smartphones, custom navigation devices, etc.), embedded black-box software on a variety of platforms, quite a large number of data formats from various suppliers, e.g. Navteq, Post Office, etc., and many other complex things (e.g. truck engine management systems). Our software is extremely complex (certainly not an n=2 problem ) and constantly evolving as new customer requirements come along, but I would never use that as an excuse to release code that contains bugs.

Simon
Post #1498691
Posted Thursday, September 26, 2013 2:07 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:45 AM
Points: 5,813, Visits: 3,734
I agree with Simon's sentiments, however, I have rarely been given the support from management (especially time) and the calibre of colleagues with the appropriate training and experience in the relevant skills (including myself at times) to deliver 100% quality software. Even when everything is going 100% there has always been something that has been forced in with pressures from those who have the power to say JFDI (Just Do It - exact phrase used twice, approximations almost every other time). It may not be right from a software development perspective but sometimes it is the right commercial decision.

Simon appears to be delivering products which have a very different nature to project work. Technically the same but commercially different. I say kudos to Simon, his colleagues and his management team.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1498710
Posted Thursday, September 26, 2013 6:44 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Yesterday @ 12:04 PM
Points: 705, Visits: 1,779
Kumbaya, all of our software is perfect!

Simon,

Sounds like you are in an company that actually encourages software quality and probably has the processes and personal to carry out that mission. Good for you.

Unfortunately many people in this industry don't work for such establishments. A good developer would not release software with known defects, but in practice, "good enough" is the enemy of "perfect" and the developer doesn't always get to decide priorities. How many shops would pass the "Joel Test"? How many non-programmers in management are making technical decisions that effect code quality? (Even our so-called industry leaders, Microsoft, Oracle and Google, still produce software that has embarrassing bugs and oversights, not to mention security holes.)

Post #1498798
Posted Thursday, September 26, 2013 9:02 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 7:11 PM
Points: 7,920, Visits: 9,646
paul.knibbs (9/25/2013)
I always like Maurice Wilkes' quote about this:

"I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."

That was back in the late 40s, I believe, so this has been going on for a while! It doesn't help that SQL, as a language, isn't really well designed for debugging--it's one of the few languages I've used where I find it faster to just rewrite a line of code that isn't working rather than try to figure out why it isn't.

The "exact instant" refered to was some time in 1948 or 1949. He never did say exactly when, as far as I could discover, but he did say it was "as soon as [Wilkes and his research team] started programming" EDSAC; that would have been before the machine was declared completed and operational in May 1949, but more than a year after design for the project started late in 1946. Your quoted text which mentions it is Peter van Linden's 1994 misquotation from Wilke's 1985 memoirs.

The Cambridge Math Lab fornighly colloquia which he established were still going striong when I worked for EE (1967-69) and I attended quite often. It was a long journey from my base at the Nelson Research Labs, so I couldn't get to to all of them, but I did meet Wilkes a couple of times and found he was even more impressive in person than in reputation.


Tom
Post #1498901
Posted Thursday, September 26, 2013 9:35 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 5:04 PM
Points: 2,487, Visits: 1,576
chrisn-585491 (9/26/2013)
A good developer would not release software with known defects, but in practice, "good enough" is the enemy of "perfect" and the developer doesn't always get to decide priorities.


Chris - as we said in the 60's "Right On Brother!"

We do not get to make the call on scope, correctness, or completeness. And often production developers in the commercial environment are embarrassed when management starts trying to find who is at fault for the failures of the product, and marketing says "We can only sell what they give us. Don't look at us, it was them!"





Not all gray hairs are Dinosaurs!
Post #1498930
Posted Thursday, September 26, 2013 9:42 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 7:11 PM
Points: 7,920, Visits: 9,646
simon.crick (9/25/2013)
"embrace the idea that code can be wrong" -- Nathan Marz

Surely this is the wrong approach, as it just gives people an excuse to be lazy.

Code should NEVER be wrong.

It is not difficult to write code that works correctly.

You just need to follow two simple rules:

1) Be crystal clear about the valid set of inputs, and throw an appropriate exception if the input is not in the valid set.

2) If you are not sure whether the logic is correct, break your code into smaller functions/procedures until it is 100% clear that it will work correctly in all cases.

Bugs only arise when people do not follow these simple rules.

Simon

That statement is hopelessly optimistic, in my view. Another esential rule is always write defensive code - yes, your point 1 is a part of that, but only a tiny part; we all know that complex operating systems, compilers, and DBMSs contain bugs, and it is necessary to recognise that, to recognise also that we don't know what all those bugs are, and to write code that tries to work despite such bugs do proper error detection, error containment, and error reporting - the whole effor management thing - not just validation of inputs with exception throwing when they are invalid. But the cardinal rule of all, far more important than anything you have said, is first know what the requirement is and often that is in fact the most difficult thing to do.
Even if one tries to follow all the rules (and there are still more, to do with avoidance of complexity, economy of invention, esthetics, resource consumption, which ought to be stated as part of the requirement but probably won't be because the requirement is almost always incomplete, which is another source of problems) the complexity of the task may be such that human limitations are likely to lead to errors - another function of defensive programming is to detect and contain these as far as possible, but as far as possible often is no going to be as far as perfection and that means that we must accept that our software will contain bugs instead of claiming that we are so perfect that we never make a mistake.


Tom
Post #1498935
« Prev Topic | Next Topic »

Add to briefcase «««34567»»»

Permissions Expand / Collapse