Software Engineering Code of Ethics and Professional Practice

Following is the short "preamble" version of the IEEE-CS and ACM endorsed Software Engineering Code of Ethics and Professional Practice (also found on the online ethics site, as a PDF, and at the ACM site):

Software Engineering Code of Ethics and Professional Practice

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices (version 5.2)

The Duct Tape Programmer Posts (Joel and Bob)

What is the Duct Tape Programmer? He is the smart, pragmatic Keep It Simple Stupid (KISS) software developer, whose top priority is to ship as soon as possible a "good enough" product (but not garbage) that satisfies the users needs. At least that's my summary from the original "The Duct Tape Programmer" blog post, by Joel Spolsky and Uncle Bob's comments on that post.

Some main points from both of these posts:

• Keep it simple. Using advanced, usually more complicated, tools and designs (e.g. COM, multithreading, C++, templates) only when absolutely necessary. Be careful of over using a tool and of over engineering the solution.
• Good (smart) software developers know when the aforementioned tools are needed and when to avoid them, and are not afraid to make the decision to use or not use them, or assert there views on the matter.
• Be pragmatic: "A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has" [Joel].
• One of the most important, perhaps the most important, feature of a (software) product is to ship the product as soon as possible. "It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point --- you're not here to write code; you're here to ship products" [Jamie Zawinski, from Joel]. Nevertheless, don't ship garbage: "The programmer who spends weeks building the perfect structure does just as much harm to the project as the programmer who hacks a bunch of crap together. Neither have struck the balance that's required" [Bob]

Here are some follow-ups by Bob:
Echoes from the Stone Age
TDD Derangement Syndrome

C++: Interoperability of Libraries Compiled by Different Compilers

Is it possible to link to libraries compiled with different compilers? I get asked this question a lot. Usually I ramble about this or that; I won't do that here. Rather, here's a nice concise answer from Rob K on stackoverflow. Quote:

• If the library is written in C++ and exposes a C++ interface: no (because the name-mangling differs between g++ and VC++).
• If the library is a static library written in C (or with an extern "C" interface): yes, but certain caveats apply.
• If the library is a DLL with a C interface: yes, but you'll have to create your own import library.

The above quote is specific to MinGW and Visual Studio, but in general the same rules apply between any two compilers. Speaking of MinGW, the Mixing Compiler page on MinGW's Wiki (and the older page here) also address this issue.

Here are more resources:

•  C++ Dynamic Library Compiling/Linking
• Interoperability of Libraries Created by Different Compiler Brands 
• C++: Dll compatibility between compilers 
• Importing a dll from a different compiler 
• Using C++ DLLs with different compiler versions 
• Can I link object files made by one compile to those made by another one? 
• Building Windows DLLs with MinGW 

PyDev: Workaround for the Undefined Class/Static Attribute Error

PyDev will incorrectly identify class (static) attributes as "undefined" if they are dynamically added to a class. Consider the following class:

class Quantity:
    def __init__(self, name, unit):
        self.name = name
        self.unit = unit

# Add some class/static attributes after class creation

Quantity.VOLTAGE = Quantity("Voltage", "volts")
Quantity.COUNTS = Quantity("Counts" , "counts")

Now, if we use a class attribute, such as VOLTAGE, PyDev will flag it with an "Undefined variable from import: VOLTAGE" error, even though it is valid.

print(Quantity.VOLTAGE) # <-- Flagged as an error

To work around this, add the annotation @DynamicAttrs to the class's docstring, as follows:

class Quantity:
    """ @DynamicAttrs """
    def __init__(self, name, unit):
        self.name = name
        self.unit = unit

Reference: Fabio on PyDev's user list.

Joel Spolsky's Talk on Being Number One (Business of Software)

Can be viewed here. Some main points I captured from the presentation:

• Make people happy.
• Put the user in control.
• Positive feedback.
• Obsess over aesthetics.
• Skins are not the answer.
• Modernist architecture is not the answer (decadence is still important in the software industry).
• Not the same as being pretty; capture and convey some message or theme.
• Observe the culture code.
• If necessary, define one and develop it.
• Care about it, embrace it.

Links: Some C++ Smart/Auto Pointer Implementations

QT
Standard Library (STL)

• Example
• Tutorial 

Boost

On Professionalism: Welcome to the Family

I've always maintained the necessity of creating a true, organized profession out of software development/engineering and computer science. One aspect of making that a reality is creating a unified "family". Sadly, the lack of professionalism and unified identity is keeping some from joining our profession and encouraging those already in it to leave. David Alan Grier in his article "Welcome to the Family" [1] writes:

Computer science has generally felt more comfortable with families of technology than with families of professionals.

professional life ... [involves] discipline, loyalty, competition, common knowledge. It [is not] something that [can] be turned into a desirable activity with some fun and games.  Becoming a professional means joining the family, with all the rights, responsibilities, and discipline that come with membership.

The field of computer science is defined not only by technical accomplishments but also by those who take the name of computer scientist.  As has happened in the past, and as will likely happen in the future, we are seeing both researchers and practical innovators question the value of identifying themselves with our discipline.  Their answers will largely depend on whether they think we have anything to offer them.

We might see a rise in membership if we offered vengeance for a child wronged, but we are more likely to be successful if we can offer an identity that promises a better and exciting future.

If we want to encourage others to join our profession, or those in it to remain, we most make sure he/she "finds value in our companionship."

References
[1] Grier, David Alan, "Welcome to the Family" in IEEE Computer, Volume 42, Issue 8, 2009