Tag: Responsability

Quick thoughts about Seth Godin’s article “Our Software must get better”

I’m a long-time Seth Godin fan, so I read with interest his recent article about software quality.

With the examples he gives of inadequacy in software – iTunes user experience, the Macintosh’s built-in address book’s slowness and difficulty with importing and exporting data, and general unreliability and lack of Macintosh-compatibility of stamps.com – he’s focused mostly on the user experience aspects of software, which I think misses a key point. I think the biggest problems for software users these days are not slowness, confusion, frustration and extra clicks – though these can be real problems. The big issue for software users today, IMHO, is in the realm of data security, transparency and privacy.

Software in general is getting really good at collecting data profiles of the people who use it. I think this can be done in an ethical, transparent and generally secure way which generates value for the software’s creator in a fair and honest exchange for the user experience that consumers want. Is that what’s happening now? Not enough to satisfy European governments, who are taking action on this issue.

Seth Godin is smart enough and experienced enough to set up a kickstarter for a better Mac address book that is fast and can handle imports. But he would like software users to take ownership of the quality of the software that they use, by explicitly paying for what they use and by insisting on a user experience that meets their needs. On a large scale, that would be a pretty radical change, which would surely have a positive impact.

For the moment, most users either don’t know what “better” is or don’t care enough to pay for it. The trend among the giants of the software industry landscape seems to be that better means “smarter”, which means “knows what you want”, which is a problem in the aforementioned realm of data security, transparency and privacy. If you collect personal information, you must protect it forever and use it in a way which is ethical and transparent. If your smart assistant in the cloud knows that you have an appointment next Tuesday with Doctor So-and-so and the Such-and-such Clinic, who else will know that? The only data which is 100% guaranteed to be private is data which is never collected.

Ironically, the respect for privacy seems to be better in free software (Mozilla, Linux, etc.) than in software which people pay for. Godin alludes to this in his point “C” as to why software is mediocre.

Seth Godin would obviously like us, the software craftspeople of the world, to insist on better user experience, and, ideally, he’s right. It should be part of the software craftsperson’s ethics to improve the user experience. It’s not always clear, though, who should be responsible for defining what constitutes improvement or deciding what time and resources should be allocated for it.

At a minimum, we as developers can strive to create software which is easy enough to change that the user experience can be improved easily once we understand what improvements need to be made. We can also strive to treat the users’ personal data as a precious commodity to be protected, we can sanitize our inputs, and we can use the best encryption techniques available for passwords and other sensitive data.

The Boy Scout Rule vs. the Pottery Barn Rule

Scenario 1 (The Blind Side)

You’re fairly new here, but it you thought it would be a good idea to rename the method “doProcessing” to “updateSalesStatistics”. It’s true, the code is much more readable now. Did you know that our largest paying customer loads our jar file and calls “doProcessing” via reflection? They’re not happy.

Scenario 2 (Danger UXB):

We had to revert your last commit. We’re 2 weeks from code freeze, and you refactored the doProcessing method. That method is 400 lines long and contains little mountains of indentations, and there’s no way to unit test it. It’s too important to risk breaking it now.

With his Boy Scout Rule, Robert C. Martin encourages us as software craftsmen and craftswomen to be brave and clean up the messes we find, at least a little bit at a time. Unless you have a team experienced in and fanatically devoted to clean code, design, and TDD plus a clear shared vision of the functional specifications, technical debt is added to your project on a daily basis. So the Boy Scout Rule proposes that each of us reduce technical debt on a daily basis, hopefully at least as fast as it accumulates.

This excellent approach sometimes runs afoul of its corporate nemesis, which is best summed up as the Pottery Barn Rule: You break it, you own it.

It can create a real dilemma for a software craftsman or craftswoman who wants to do the right thing but can not promise that every improvement poses no risk. We see in the first scenario above that we can be blindsided by undocumented usages of the code which are not enforced by the compiler. This kind of problem is technical debt that keeps on giving. In the second scenario above we see technical debt which protects itself using fear. It’s like an unexploded bomb, but there’s no bomb squad, just you and the people who will blame you if it explodes after you’ve touched it.  If it explodes when left alone, responsibility for the explosion is diffused.

Overcoming these sorts of blockages requires courage, an effective code review process, and what I might call “good management”. According to an extensive internal study done by Google, the number one key to having an effective team is “psychological safety: Can we take risks on this team without feeling insecure or embarrassed?”. That’s partially down to management, but I think it’s also linked to the number 2 key: “Dependability: Can we count on each other to do high quality work on time?” That’s where the developer can make an impact. If most of the time you get it right when you take a risk, the team will likely cut you some slack on the rare occasions when you don’t.

 

Uncle Bob’s Oath Proposal

Robert C. Martin recently proposed an oath for the software professional. I applaud Uncle Bob’s efforts to encourage higher standards of professionalism, which have inspired me personally, but his oath is based on premises which seem unrealistic to me. The oath has already received much intelligent criticism, from Ron Jeffries, for example. Uncle Bob seems to want us to have a “priesthood” aspect to our profession, but it’s based on questionable analogies.

We are not like doctors and lawyers, who receive quasi-governmental powers in exchange for a difficult certification process, a code of conduct and possibly governmental or quasi-governmental oversight (which, by the way, does not always eliminate abuses of the aforementioned powers and sometimes serves to cover them up). We are not like academics, either, where a “priesthood” is necessary to protect people who invest time and resources into a career path which in many cases has limited commercial value (For example, how many of us would pay big bucks to hire someone to read Sanskrit or analyze Tolstoy or survey the spectral emissions of a distant galaxy?).

Clearly, we have some important issues to address in software development, including:

  • technical debt
  • ethical implications of the products we develop (the potential for fraud or invasion of privacy, for example)
  • risk of project failure
  • handling and security of sensitive data
  • the rapid and continuous proliferation of new tools and approaches (and the need for training/education that this creates)
  • diversity issues (notably gender, race, and age)
  • repetitive strain injuries

Uncle Bob’s oath attempts to address a few of these issues, putting much of the responsibility on the individual developer, who is assumed to receive in exchange for this responsibility the additional autonomy and the time to do his or her job as he or she sees fit. That sounds nice, but software development is often a collaborative team effort, often serving a goal which is not chosen by the developers themselves, so responsibility should be shared.

I think a lot of companies could gain a competitive advantage by treating programmers as respected, autonomous professionals and to provide them with training or time to self-train (and some of them actually do it). However, I can’t support an oath which assumes that all employers do that to the extent assumed by Uncle Bob.

Here’s my humble (rough draft) revision (my additions in italic) of Uncle Bob’s oath, with commentary in blue:

I Promise that, to the best of my ability and judgement:

  1. I will not produce harmful code which is intended to defraud or to harm innocent victims.(Uncle Bob’s version would eliminate from the profession anyone programming weapons systems, for example. My version is more permissive but still covers cases like Volkswagen and Bernie Madoff )
  2. The code that I produce will always be my best work. I will not knowingly release code that is defective either in behavior or structure. conceal defects in the code’s behavior or structure from my employer or customer.(Living with defective software is what made certain software companies what they are today. Far be it from me to say they made the wrong choice, but an ethical developer will be transparent about this choice. Many developers have loyalty clauses in their contracts which would prevent them from announcing a defect publicly, but it’s always possible to inform the product owner.)
  3. I will produce, with each release, a quick, sure, and repeatable proof use the most appropriate techniques available to me, taking into account my employer’s or customer’s wishes, to ensure in repeatable fashion that every element of the code I produce or modify works as it should.(I think the employer/customer wishes and business needs can not be ignored just because there’s a “right way” to engineer, and a developer can’t take responsibility for the entire base of legacy code for a short-term add-on project.)
  4. I will make frequent, small, releases so that I do not impede the progress of others. There is no number 4. (This is micro-management by oath. If a company has a 6-month release cycle, I can encourage them to do 2-week sprints, but it’s not always my call, and they might not be ready to handle it.)
  5. I will fearlessly and relentlessly improve the code I work on at every opportunity. I will never make the code worse without a commitment to correct the worsening by an agreed-upon date.(This one is not bad, if you interpret it such that “every opportunity” gives some leeway to respect the wishes of an an employer who discourages certain code improvements. I added a fail-safe for cases where a short-term need requires a quick hack to be repaired later. I also added a specifier so that I’m not responsible for all the code in the world but only the code I touch. I removed the notion of fearlessness because I know of code that only a fool would change without fear.)
  6. I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.(The first sentence is enough. The second is too inflexible.)
  7. I will continuously ensure share information to facilitate that others can cover for me, and be open to receiving information to facilitate that I can cover for them.(Staffing and how to cover for an employee’s absence are management’s call – a professional who is not a fully independent contractor should facilitate management in this effort but should not have responsibility for it. )
  8. I will produce estimates that are as honest as possible both in magnitude and precision. I will not make promises without certainty transparency about uncertainty.(Honesty and transparency are important for estimates, but no one can eliminate all uncertainty. Some slack should also be built into estimates to account for uncertainty and interruptions and tasks not directly related to the development itself.)
  9. I will never stop continue to learning and improveing my craft.(Let’s not judge the developer who chooses to attend their child’s piano recital instead of going to a coding dojo or a user’s group meeting. We have a long-term commitment to improve, subject to short-term interruptions.)
  10. I will keep informed about security issues and follow important security guidelines as appropriate in order to ensure the security of sensitive data.(This is my own addition. It could be covered under #2 and #9)
  11. I will not knowingly post a complete solution to what is obviously a computer science homework problem on StackOverflow or other public forums.(A recent pet peeve of mine. It’s good to help people learn, but helping someone cheat while spoiling a good homework question for posterity seems like a breach of ethics.)