Write great code. - Steven Feuerstein.com

Download Report

Transcript Write great code. - Steven Feuerstein.com

Software Developers (and DBAs and other techies)

Heroines and heroes of the 21 st Century

by Steven Feuerstein [email protected]

Ah, to be a hero or heroine!

* * Aung San Suu Kyi

Copyright Steven Feuerstein 2004

Hero? Heroine? Us?

Who are you kidding, Feuerstein?

A hero is "a person noted for feats of courage or nobility of purpose, especially one who has risked or sacrificed his or her life."

courtesy of www.dictionary.com

Copyright Steven Feuerstein 2004

The Creed

of the

Heroic* Programmer is actually very simple:

Write Great Code.

Stop Bad Code.

* I will use the term "hero" to refer to heroic figures both male and female.

Copyright Steven Feuerstein 2004

How can a programmer be a hero?

 Everyone and anyone can be a hero. There is certainly no shortage of need.

 First, we must understand our unique and important powers. (Yes, we can even be

Super

heroes!)  Second, we must recognize the challenges faced by humanity.

 Third, we must each individually make our choices.

Copyright Steven Feuerstein 2004

A Tornado and AOL....

 How are they similar? How are they different?

Copyright Steven Feuerstein 2004

Email Paypal TRW Credit Agencies

The source of our power...

FBI, CIA, NSA, DSA

 More and more of the lives of more and more people are spent in or constrained in some way by software and computerized systems.

Instant Government Messaging bureaucracies Internet a.k.a., the "web" Internal MIS apps Ebay HMOs AOL Amazon

Copyright Steven Feuerstein 2004

"You got the power..."

    Every one of those systems are written by people like us.

The constraints on behavior, on communication, on possibility are all encoded by....us.

In a sense,

code is a new kind of law

* and we are the ones who write the laws. True, we don't generally design the rules that we are putting into the code, but it simply can't happen without our willing participation.

* See Lawrence Lessig, Code and other laws of cyberspace Copyright Steven Feuerstein 2004

With great power, comes great responsibility

 Our brains, our fingers, our software.

 We bear responsibility.

 What is the nature of that responsibility?

– Most fundamentally, we are Guardians of Rationality.

– More pragmatically, we are Free Agents who choose to type what we type, and know exactly what goes on "behind the curtain." Copyright Steven Feuerstein 2004

Guardians of Rationality

IF a THEN b; IF b THEN c; IF a or b THEN IF c THEN ELSIF END IF; ELSE ...

END IF;

 We must be champions and proponents of the use of logic and fact-based thinking among humans.

Copyright Steven Feuerstein 2004

Stop bad code.

If not us, who?

If not now, when?

Aw, gee, what's the harm in badly designed/written code?

JANUARY 03, 2000 - The first printed mention of Y2K was made by Paul Gillin in Computerworld on Feb. 13,1984; the first printed warning about Y2K was issued by Peter de Jager in the pages of Computerworld on Sept. 6, 1993.

Y2K Y2K costs will reach $75 billion, predicted Peter deJager in the Sept. 16, 1993, issue of Computerworld.

Y2K repair costs will reach at least $100 billion and may go as high as $114 billion -- $365 for every man, woman and child in the U.S., reported the U.S.Department of Commerce in November 1999.

The estimated worldwide cost of fixing the Y2K bug,according to analysts: Cap Gemini America Inc. -- $858 billion; Gartner Group Inc. -- $600 billion; International Data Corp. -- $300 billion.

Copyright Steven Feuerstein 2004

How can programmers stop bad code?

    By accepting our responsibility and playing active, informed roles in every one of our software projects.

By acting as safeguards for those around us. We understand the reality of software programming. We know that bugs are inevitable. We know how poorly software is generally tested.

We can raise alarms, we can blow whistles. We can refuse to participate, refuse to be complicit.

But first, allow me to present you with a business plan....

Copyright Steven Feuerstein 2004

Business Plan – pg 1

Global Lottery for All: e-lfa!

 Elfa is a global lottery, with a weekly minimum pot of

$100M

. Customers pay $5 a ticket, can buy as many tickets as they like.

 We use a very powerful and sophisticated computer designed and constructed by top notch scientists at Elfa to pick the winning number.

Total lottery income in USA in FY2004: $48,801,000,000.60

FORTY EIGHT BILLION DOLLARS!

Copyright Steven Feuerstein 2004

Business Plan – pg 2 1 7 7 3 4 1 9

The WinBox Way

 Understandably,

WinBox

must be very secure from tampering. So it is a sealed "black box." No one from outside of Elfa is allowed to examine it or monkey around with it.

 Each week, I go on-line and on television and on radio to announce the winner. In front of witnesses, I press the big red button on

WinBox

, and a number appears. If you chose that number, you are the

big winner!

Copyright Steven Feuerstein 2004

How

R$CH

do you want to be?

 Lotteries are big money makers.  You stand to realize an ENORMOUS profit on a lottery with global scope.

– All we need are millions upon millions of people who will buy tickets each week. – And they will. It is a proven fact, occurring daily all over the world.

 How much will

you

invest in Elfa?

Copyright Steven Feuerstein 2004

What? You don't trust me? Me?

 It does come down to trust, doesn't it?  There are many reasons to think that my business plan will fail, but primary among them: Why would anyone trust my WinBox to randomly pick the winner?

Copyright Steven Feuerstein 2004

The interesting thing about those old-fashioned lotteries....

Hard to rig, to trust.

Which is not something you can say about the WinBox.

Copyright Steven Feuerstein 2004

And now let us consider....

electronic voting systems

"GEMS is a state of the art election management software package that runs on Microsoft's Windows operating system."

-- http://www.diebold.com/dieboldes/GEMS.htm Copyright Steven Feuerstein 2004

Democracy in trouble?

 We face a severe challenge to the most fundamental aspect of a successful democracy: – Faith in the process and fairness of voting.

 This is not a new problem, but the rapid, widespread introduction of computerized voting may bring us to a crisis point.

Copyright Steven Feuerstein 2004

Is electronic voting inherently bad or unavoidably risky?

 I don't think so, though I tend to be a Participatory Luddite when it comes to voting.

 Electronic voting is, however, easier to manipulate and much, much hard to verify if the proper steps aren't taken.

See IEEE Spectrum, October 2004, "The Perils of Polling", for an excellent roundup of the technology issues: http://www.spectrum.ieee.org/WEBONLY/publicfeature/oct04/1004poll.html

Copyright Steven Feuerstein 2004

The programmer perspective on e-voting machines should be....?

 They are computer systems.

 They contain complex software.

 They are almost certainly not sufficiently tested.

 They are almost certainly not 100% secure.

 Why would we trust a private company's assurances?

Ok, this is the "theory." What's the reality?

Copyright Steven Feuerstein 2004

Cause for concern?

1. California, 2003: Diebold installs uncertified software without notifying authorities.

memory results in failure to count 12,000 of 48,000 votes.

4. Alameda County, 2004: Diebold control modules fail to start up.

5. Orange County, 2004: Hart InterCivic Inc. DREs trip circuit breaker and shut down when batteries die; voters are turned away from the polls.

6. Orange County, 2004: Hart access-code confusion causes 7,000 voters to receive the wrong ballots.

7. San Diego County, 2004: Diebold DREs lose votes; control modules fail to start up properly.

8. Bernalillo County, 2002: Insufficient memory results in failure to count 12,000 of 48,000 votes.

9. Arapahoe County, 2004: Failure to maintain DRE battery charge results in expenditure of more than $100,000 to replace batteries.

10. Dallas County, 2002: Election Systems and Software Inc. (ES&S) iVotronic systems mark incorrect choices on voting screens.

11. Harris County, 2003: Hart DREs don't start; voters must use makeshift paper ballots.

22. Broward County, 2004: ES&S DREs

won't tabulate votes.

Who at the polling

marked on-screen.

station is going to

16. Muscogee County, 2003: DREs register "yes" when voters vote "no."

take care of these

18. Montgomery County, 2004: Diebold DRE shows incomplete ballot when font is magnified.

19. Sarasota County, 2004: ES&S DREs fail to count 189 votes.

problems?

21. Broward County, 2002: ES&S iVotronic error results in failure to count 22% of the votes.

22. Broward County, 2004: ES&S DREs lose 134 votes; margin is 12 votes.

The "users"?

24. Miami-Dade county, 2004: Severe audit log bug in ES&S iVotronic system is revealed; it had been detected nearly a year earlier.

Enter Bev Harris, heroine.

(www.blackboxvoting.com)

 She didn't accept the official versions and assurances provided by Diebold and state election officials.

 She found an unsecured Diebold corporate FTP site with 40,000 documents and program listings.  And she (with others) performed some code review.

Gee, you'd think Diebold would have thanked her. Free code review!

Copyright Steven Feuerstein 2004

Some findings...

 GEMS maintains multiple sets of "books" or ledgers, the tabulation of the votes.

 At least one of these ledgers could be modified through – I kid you not – Microsoft Access.

 Passwords could be hacked and bypassed.

 Audit trails could be modified.

 The software and data could be modified via remote access.

Copyright Steven Feuerstein 2004

Electronic voting today is a matter of national debate and attention.

    Bev Harris and a number of other software experts* have played a major role in exposing problems and pressing for solutions.

Fair voting in a democracy should not be a political issue, it should be a verifiable reality.

The politicians aren't going to make this happen.

Only computer scientists and professionals can do this work in a rationale, convincing fashion. * In particular, Aviel Rubin at John Hopkins University.

Copyright Steven Feuerstein 2004

You can get involved in the tech effort to guarantee a fair vote.

 Verified Voting Foundation/TechWatch – "Are you a technology professional interested in election integrity? A geek who believes every vote should be recorded as intended? A techie who stands for reliable and publicly verifiable election systems?"

http://www.verifiedvoting.org/techwatch/

Copyright Steven Feuerstein 2004

Only you can stop bad code?

 We have all faced moments in our career when we felt the tension of a moral dilemma, when we felt we were being asked to cross the line, or watched others cross that line.

 We each have a deeply personal, individual choice to make: let it ride or take a stand?

 I hope you understand better the special role you play and the potential implications of

your

choice.

Copyright Steven Feuerstein 2004

Write great code.

This simple mantra should inform all of our programming efforts.

But what does it mean and how do we do it?

Four steps YOU can take.

1.

2.

3.

4.

Don't repeat anything.

Remember you are not a machine.

Write tiny chunks of code.

Integrate unit testing into your development process.

Copyright Steven Feuerstein 2004

1. Don't repeat anything!

 This is the #1 tip for developers to follow.

 Develop an extreme allergy to repetition. Become intolerant of déjà vu code.

Hide the business rules.

Re-use common utilities.

Cover up for the built-ins.

Generate the boring stuff.

Don't cut-and-paste code.

No VARCHAR2 declarations.

Don't repeat SQL.

Don't hard-code literal values.

Copyright Steven Feuerstein 2004

  Qnxo: Quality In, Excellence Out.

Active mentoring software that makes reusable code and pattern-generated code a practical reality.

Copyright Steven Feuerstein 2004

2. Remember: you are not a machine

 Computers are machines. You are a human being. – To be a programmer, you have to

think

like a computer.

– But you don't have to

live

like a machine.  Key human being tips: – – Drink lots of water.

Take frequent breaks. Get up, stretch, move around,

And ask for help before you get desperate!

Copyright Steven Feuerstein 2004

3. Write tiny chunks of code.

No executable sections with more than 50 lines of code!

 Keep your executable sections small, readable and manageable.

 Use top down design – Break up big, seemingly impossible problems into smaller more manageable problems.

– Local modules come in very handy here.  Create lots of small, focused packages.

Copyright Steven Feuerstein 2004

Automatic loading of argument definitions: a quick example

 Qnxo provides a script repository.

– Scripts can have arguments.

I need to add the ability to scan the contents of a script's source and identify any argument definition comment lines: #ARG arg_name | arg_description | arg_default I will then automatically create an argument for that script.

Example: {91879C86-D4B4-4675-81A4-C10C7676CACB}

Copyright Steven Feuerstein 2004

Take it step by step, and top-down.

PROCEDURE ) IS , , load_arguments ( id_in overwrite_in delimiter_in IN IN IN Sg_Script_Tp .

id_t BOOLEAN DEFAULT FALSE VARCHAR2 DEFAULT NULL

Standardized types for complex structures

l_script_source Sg_Script_Source_Tp.sg_Script_Source_tc; ...

BEGIN l_script_source := Sg_Script_Source_Qp .

for_script_id ( id_in );

Use program in table API to get all source rows.

l_index := l_script_source .

FIRST ; END WHILE ( l_index IS NOT NULL) LOOP parse_argdef add_argument l_index END LOOP; := ( ( l_script_source l_arg ); ( l_index ).

text l_script_source .NEXT ( l_index ); , load_arguments ; l_arg );

Top-down specification of complex internal logic.

Copyright Steven Feuerstein 2004

4. Integrate unit testing into your

development process.

 For too many of us and for too much of the time, unit testing is all but ignored.

– The result is much buggier code and code that is much more difficult to maintain and enhance.

 It's time to get serious and integrate testing into the development process.

utPLSQL

and the

Ounit

interface offer the best chance of doing that today in the world of PL/SQL.

Visit www.ounit.com

and shift testing paradigms!

Copyright Steven Feuerstein 2004

Write great code – stop bad code.

 We all know we should write better code – so let's aim to write GREAT code.

 And I hope that you all now have a clearer understanding of the role we – each and all can play far beyond the code itself.

 It's up to each of us to decide our path.  But it

is

, in some very fundamental ways, going to

be

up to us.

Copyright Steven Feuerstein 2004