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)

Software Engineering Dead Tidbit

There has been conflicting conclusions ("take-aways" if you like) from Tom DeMaroc's article Software Engineering: An Idea Whose Time Has Come and Gone? [1]. As an example, see Jeff Atwood's blog Software Engineering: Dead? and the many comments at the end. I won't re-hash any of what was said there. But I will says this: regardless of whether SE is dead or not, we must continue to strive for the professionalism found in other engineering fields. This includes establishing best engineering practices, forming professional organizations, defining our responsibilities to the public, defining paths of entry, defining codes of ethics and enforcing them, requiring certification and/or licensing, and more.

That aside, my own tidbit from this article is the project management advice captured in these quotes:

Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much.

and

So, how do you manage a project without controlling it? Well, you manage the people and control the time and money.You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go.”

[1] Tom DeMarco, Software Engineering: An Idea Whose Time Has Come and Gone?, IEEE Software, 2009.

The Manifesto for Software Craftsmanship

I came across the following well intentioned manifesto the other day. Quote:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration, but also productive partnerships

The above is quoted from The Manifesto for Software Craftsmanship.  Dr. Dobb's Agile Update 03/09 describes the above in more detail, and also the Agile Manifesto, from which it is derived.

The manifesto is a concise set of ideals all practicing professional software developers should follow. I also suggest adhering to 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), perhaps even more so, given the status of these organizations. The short form (i.e. preamble) is:

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)

Business Analysis, Software Engineering, and Our Profession

At the insistence of my employer I completed a Business Analysis course in gathering and documenting user requirements. I expected from the title and description it was about gathering business requirements, which in my mind are high level requirements expressed in business terms about how a solution (which may or may not include a software system) to a business problem should fit with the business goals, address business needs, and bring value to the organization. As there was no hint of software engineering in the course description, I was thinking this course could not be about software (or systems) requirements engineering I first learned in school and practiced for years.

I was wrong.

A rough guess: 90% of the material was straight from classical software engineering requirements elicitation and documentation courses taken in university. I was thinking while sitting through this course: Is most of this stuff not simply a part of software engineering? Why the silly name Business Analysis, like it is a distinct profession outside the domain of software engineering? And, how can a class full of software developers not know this stuff already? What kind of education do they have? Where did they do their training to become software developers and not learn this stuff? Disturbingly, many in this course have been building software for years and are calling themselves software developers.

I suspect many "software developers" lack other software engineering fundamentals as well. Consider the core courses for a certificate in Business Analysis: How to Gather and Document User Requirements, Testing for Business Analysts, Object Orientation for Business Analysts, and Object Oriented Modeling. These are topics all software developers should be intimately familiar with. Obviously, some of us are not. But why not?

I believe the answer lies in the lack of a professional organization that certifies (and licenses?) software engineers. Such an organization would ensure quality engineers by mandating appropriate education, training, and experience, and establishing codes of ethics and professionalism. Even though a lot of software is built to run critical systems (think about software in the medical, engineering, banking, and insurance fields, to name a few), we do not have any regulations on who is qualified as a software engineer to build such systems; i.e. there is no regulatory body to ensure those who practice our profession are qualified to do so. In the words of Bjarne Stroustrup: "I find it appalling that you can become a programmer [software engineer] with less training than it takes to become a plumber" [1].

The lack of required and approved software engineering training has resulted in many developers having little or no requirements elicitation and documentation knowledge (not to mention other software engineering fundamentals). This is a fundamental part of the software engineering process, and many in our profession are not prepared to do it. What has resulted is a need in the business world to fill a void created by inadequate and under qualified software developers. Hence, Business Analysts, out of necessity, have expanded their role to do what good Software Engineers should be doing.

My understanding from this course is that Business Analysts are gaining evermore respect in our field and are leading the way to certification on their own. Good for them. If we as a group of software development professionals (software engineers, computer scientists, programmers, and the like) can't organize ourselves and bring some professionalism to our discipline, more and more of our field will be shifted to other professionals who can. I can see this already happening. The Business Analyst is now somehow seen as much more than the Software Engineer, fulfilling major roles in the software engineering process (I'm not saying BAs don't have a role to play, just not as software engineers). That leaves us as "just coders", unprofessional worker bees, with no control over our own profession. Shame on us.

Every true profession eventually forms an organization to ensure integrity and quality of the professional, and to protect the public, the business world, and the practitioners. Such organizations also ensure the discipline remains in practitioner's hands and those practicing it are properly qualified (education, certification, licenses). Consider teachers, lawyers, doctors, pharmacists, electricians, and, my God, in my neck of the woods even mortgage brokers. They have all professionalized. Its time we grow up and do the same.

References

[1] James Maguire, Bjarne Stroustrup on Educating Software Developers, Datamation, http://itmanagement.earthweb.com, 2008

The Ad-Hoc Approach Can Work, Sometimes

Joel Spolsky's introduction to his article How Hard Could It Be?: The Unproven Path at Inc.com states that he has broken seven rules about creating a technology venture. All the rules (except maybe the last one) also pertain to executing software development projects. If I were to draw a conclusion from this article it is this: you can, sometimes, create useful quality software in a reasonable time frame without following established approaches --- i.e. using an ad-hoc approach can work. The article gives one example where this approach succeeded. A few of my own projects and some of my colleagues have also succeeded in spite of breaking most of these rules. I'm welling to bet a great percentage of the single person or small team open source projects have also been successful using the same approach.

Don't get me wrong, I'm not advocating the ad-hoc approach for software development projects. In fact, even suggesting so leaves a bad taste in my mouth and gives me a sick belly. But I have to be realistic, for certain types of projects, it does work. I believe the success of using this approach depends heavily on the project team and the nature of the project. Off the top of my head, here are a few ingredients the project should have to use the ad-hoc approach successfully.

• The team must be small. The larger the team the less chance the ad-hoc approach will be successful.
• The entire team must consist of excellent developers: smart, experienced, knowledgeable, passionate (Joel states this in a slightly different way at the end of his article).
• The team must have a deep, intrinsic understanding of the requirements for the software.
• The team must believe in and take ownership of the project.
• The entire project should be built in-house --- minimum amount of collaboration with and dependencies on external teams, especially those from other companies.
• The software is being built from the ground up.
• The product is not an "enterprise solution" built in an IT shop where
  • lots of red tape, bureaucracy, hierarchy, turf wars, and office politics can get in the way; and,
  • the software being built is not tightly coupled with lots of other enterprise software.

With these points in mind, lets revisit Joel's seven broken rules (sometimes liberally paraphrased) and try to identify when and why these rules can be broken without negatively effecting the project. (The following comments are opinions based on my experiences, no research on their validity has been conducted.)

Hire only the best programmers. I whole heartedly agree with this rule for all projects: it can't be broken without consequences. Joel thinks he has broken this rule by hiring Jeff Atwood and Jeff's team of developers without checking if they "could write good code". I don't think he really broke this rule at all since Jeff's reputation has being an intelligent, passionate, good developer is generally accepted by the development community. There is very little risk in hiring a developer as well respected as Jeff.

All developers and management staff must be in the same office. When developing software before mid 90's, this rule could not be broken. This is no longer the case, especially for projects with a small number of developers. All team members can effectively and efficiently communicate, perhaps more so, using readily available communication and collaboration technology, including the basics such as email, chat, video chat, twitter, wikis, phone, video phone, and video conferencing. As an example, consider 37 Signals, a company that embraces the distributed model in addition to building tools to help support it.

Plan before proceeding. Planning is always done, but when, how much, how formal, by who, and if it's documented or not can change for each project. For projects that meet most of the criteria outlined above, it is sometimes OK to do minimalistic up front planning, as opposed to complete project plans where the entire project is broken down in many fined grained tasks and extensively documented. The project plan can occur in the team leaders heads, perhaps with some notes so things are not forgotten (but with minimum detailed formal documentation), and keep at a very high level. The plan, written down or not, is given just enough detail to get the project going and keep it going from one major task (short phase) to the next. The plan is iteratively fined tuned and changed as the project proceeds. Task level planning also occurs as developers plan how best to tackle the next new task. Again, this is very informal and may not be documented.

Issue tracking. For new projects you can probably make do without a formalized tracking system, mainly because most issues (e.g. bugs) will be identified after the project is done and the product is in use. Nevertheless, I would recommend some place where developers can note potential improvements and known unresolved issues they encounter during development. In the most basic form, these items can reside in code comments flagged with tags like TODO (which can be automatically extracted into to TODO file using a simple script), or in a simple TODO.txt file at the root of the project. For long term products with on going maintenance and feature development, and where many different developers have to work on the product, issue tracking is a must. A sophisticated system may not be necessary, but ideas, bugs, issues, features, and tasks need a centralized place to live so

• issues are not forgotten as different developers work on the product over time;
• a place exists to record discussions and information gained about the issues;
• issues can be organized (in particular they can be prioritized);
• issues can be effectively communicated to all team members;
• responsibility for issues can be assigned, tracked, and communicated; and
• it help managers track issues and their status, progress on addressing them, and in planning for new phases of development.

Test software before releasing it. Unless you have perfect developers, I don't think this rule can be broken. What changes is who does the testing, how formalized it is, the types of testing performed, and when it is done. I would argue that for projects with really good, experienced developers, you can probably minimize the amount of formalized testing since (1) the bug per line of code introduced during construction will be low (compared to inexperienced, bad developers), and (2) these developers will do significant testing as they develop. For small or new projects that developers are passionate about, they will also do the end user testing themselves: no formalized testing teams necessary. In some cases, it may be appropriate to release the software in alpha and beta states to get user testing in the field, further reducing the need for formalized testing and test teams. In many cases, such as mission critical software and software which must interface to existing system (especially legacy ones), this ad-hoc approach may not be sufficient nor efficient.

Create schedules to ensure a project is delivered on time, within budget, and meets the requirements. For some projects, especially new projects where the software being built is charting unexplored territory, detailed schedules may not be necessary or of little use because the requirements and/or the tasks that need to be completed and the complexity of them is not well understood (See Frequently Forgotten Fundamental Facts about Software Engineering). Estimates are generally so poor that they are often no better than a general all encompassing guess anyway. Alternatively, the project might be small, will understood, and the developers are very experienced in building similar software, so developers know exactly what needs to be done and can give an accurate encompassing estimate such as "6 to 8 weeks" thus reducing the need for detailed schedules.

Decide on how to make a profit before building the product and measure its success by profit. This rule is about the business side of software development, so I won't comment on when and why you can break it. I will state that a project can be classified successful without making a profit. For example, it is useful to someone, it has quality, and it meets its requirements. Many open source projects are definitely successful, but they make no profit. The point Joel makes about building useful software first, then worry about making profit from it later, reminds me a lot of Steve Yegge's article Business Requirements are Bullshit.

References

1. Joel Spolsky, How Hard Could It Be?: The Unproven Path, Inc.com, 2008.
2. Steve Yegge, Business Requirements are Bullshit, 2008.
3. Robert Glass, Frequently Forgotten Fundamental Facts about Software Engineering, IEEE Computer Society, 2008.

Robert Glass' Fundamental Facts: A Reminder

IEEE Computer Society has made public an article entitled Frequently Forgotten Fundamental Facts about Software Engineering [1] by Robert Glass, author of the excellent software engineering book Facts and Fallacies of Software Engineering. Although I believe all software developers could benefit from reading this article, it seems especially relevant to team leaders and managers. I'm sure most seasoned professionals are aware of these facts already, but as the title suggests, it's good to be reminded every now and again. A few juicy tidbits inspired me to rant a little. For those who want to build a great development team, remember that "good programmers are up to 30 times better than mediocre programmers"; moreover, good programmers are far more important to building great software than tools and techniques [1]. I have witnessed those in upper manager who believe that all is needed is a bunch of code monkeys, who can work the longest hours possible with the lowest pay possible coupled with the latest fad in development tools. If you throw enough programmers at the problem you will probably get the job done, but I'm willing to bet the product will be over budget, will be hard or impossible to maintain, will be buggy, and will certainly not satisfy the customer. In other words, it will not meet the common definition of quality software outlined by Glass: portable, reliable, efficient, human engineering, understandable, and modifiable [1]. In the end, the product will cost your company more than if you started with a great team up front. Higher the best and brightest, not the cheapest. Regarding estimation, Glass seems a bit pessimistic, but is so funny because of his brutal truth. In a nutshell, estimates are "done at the wrong time ... (at the beginning of the life cycle ... before the requirements) ... " and " by the wrong people ... (upper management and marketing)", thus "software projects do not meet cost or schedule targets. But everyone is concerned anyway" [1]. Priceless! I generally suggest to clients and/or management that estimates should be made after the requirements are done when the problem is better understood. But as pointed out by Glass, and corroborated by my experience, this rarely occurs. Generally a client wants product X by date Y within budget Z. Madness. References [1] Robert L. Glass, Frequently Forgotten Fundamental Facts about Software Engineering , IEEE Computer Society, 2008 [2] Robert L. Glass, Frequently Forgotten Fundamental Facts about Software Engineering, IEEE Software, vol. 18, no. 3, 2001, pp. 112,110–111 (The original publication)