The words I use speak so loudly I can’t hear what I read.

People like their own words. They don’t like to be forced into the hell of words they don’t own. So, as a software developer I’m constantly learning other peoples words. I have found software that speaks in the user’s vocabulary is easier for the user to learn and use. There is less resistance for adoption because it is less work for the user to operate. Don’t call an aircraft a unit nor an article a content item. Talk their lingo. Make your software configurable to talk to users in their tongue. Learn the language yourself. You’ll have a more effective system that is cheaper to deploy and support.

Interview Skills for Developers

 

My company has been considering hiring another developer.    It got me thinking about some concrete things to do in preparation for an interview.  This is not an exhasutive list, just some ideas I jotted down at lunch.

  • Think about stories that demonstrate your experience and successes
  • Ask questions in the interview to learn what it is really like to work in the company.
  • Be ok with saying “I don’t know” instead of being vague or making things up.  On the other hand, having an idea of where to start after “I don’t know” seems like a good thing.
  • Rember that the interview team is listening to you talk and comparing that to your resume.  Be consistent!
  • Remember to look around at interview participants – not just one person
  • Ask questions to learn about the viability of the organization
  • Listen to what is said and not said during the interview conversation to better judge the organization culture
  • Assess the interview pace – fast, medium, slow.  What is that telling you?
  • Know what you want – for example, intellectual challenge, opportunity to make a certain amount of money, risk aversion.
  • Work style – collaborative, competitive, dysfunctional, individual

Like I said, this was the output of some lunchtime thinking.  There are tons of good resources out there – a little bit of awareness during an interview can help out alot.

Trust on the Other Foot

Who do you trust?  Your family?  Significant other?  Your colleagues?  Your client? Your dog?  Your goldfish?  The somewhat wilted potted plant in the corner?

The “who do I trust” perspective is common to all of us.  But it is really only half of the trust equation.

There’s the “Other Trust” I sometimes forget about.  And when I do, it smacks me in the back of the head and giggles.

Then, I stop and ask myself  “Who trusts me?”  and “Why?” or “Why not?”.

I’m working on doing this before I get whacked in the head.  I recommend thinking about the “Other Trust” once in awhile.  It’s a good way to check on the quality of your relationships – and how you are doing with them.  Before you get smacked in the head 🙂

WiFi Encryption

There are several different encryption options for Wi-Fi devices.

 These include:

  • WEP – uses RC4
  • WPA-Personal – uses TKIP encryption
  • WPA2-Personal – uses AES encryption
  • WPA2-Mixed – uses AES or TKIP encryption
  • WPA-Enterprise – uses shared key
  • WPA-Radius – integrated user authentication

 

OOAD Process

I’m jotting this down for future use.

Steps:

  1. Domain model
  2. Functional requirements
  3. User stories/use cases
  4. Robustness analysis
  5. Sequence diagrams
  6. Code

This is based on some initial reading of the ICONIX process.

Other

  • Class design
  • Class implementation
  • GUI design
  • GUI implementation
  • Database design
  • Database implementation
  • Refactoring of all system elements as required
  • Unit testing
  • Continuous integration
  • Keeping cost of change in system low
  • Architecture – identification of major blocks – hardest to change

Software Quality Assessment

I recently came across some questions about software quality that got me thinking assessing existing software. As a software developer and consultant, I’ve participated in many conversations about software quality. Here are some tools I’ve used in conversations about software quality.

1. Atrtributes of software quality of an existing system

Some of my principal concerns with software quality when I’m evaluating an existing system include:

a) How well does the software meet the user’s needs
b) Can an average user make use of the software reliably enough to get to a desired outcome
c) Ease of maintenance and enhancements
d) Technical soundness of system, primarily severity and number of open defects, frequency of system errors and crashes, and perception of stability by system users

2. Convincing others of your assessment

Historically, I’ve not been successful jamming ideas into peoples heads – they seem to get upset and resist. However, if I can involve them in a conversation about quality – and try to understand their perception – and set an example for them, often we are able to come to terms on a common definition. Even if it isn’t perfect, at least I know what to do to meet their expectations (today).

I recently read a story that I think describes this idea. Two developers walk into a village – and are told by the villagers there is an evil monster on the loose – and point to a watermelon. Both developers want to help the villagers understand that watermelons are not monsters. The first developer attacks the watermelon, easily defeats it and proceeds to eat it – trying to show the watermelon’s helplessness. The villagers find this killing and eating of monster flesh monstrous. The second developer lightly agrees with the villagers – and proceeds to share his knowledge of melons.

My short answer (now that I’ve dragged you through the longer one) is that I try to get them to convince me. Often we end up in a mutually acceptable definition – sometimes we don’t.

3. Quantifing software quality

Anything can be quantified (e.g. this software has blue quality). However, we lack rigorous, well defined industry standards to allow us to do this definitiely for all software systems. The final attributes of software quality are often subjective and context dependent. 

If an engineering team doesn’t have a scheme in place to quantify quality – it should create one. A basic scheme I’ve seen teams use in the past is:

  1. Number of open severe defects
  2. Client satisfaction with product
  3. User satisfaction with product
  4. Ability of engineering team and client to openly and effectively communicate
  5. Difference between desired frequency of use and actual frequency of use of the system
  6. Ability of client to operate and maintain the system
  7. Ability of the engineering team to evolve the system

4. Measuring software quality

A method I have used looks at some basic attributes of a software system for quality measurement:

  1. Outstanding defects and frequency (critical defects count more)
  2. User satisfaction with system
  3. Cost of ongoing maintenance for defect removal
  4. Future plans for system (low quality systems often have a replacement plan earlier than good systems)

5. Relationship between software quality and system scope, cost and schedule

I generally follow the old saying “Good, Fast, Cheap – Pick any 2”. Give me 2 degrees of freedom, and I have a fighting chance to still develop a system of reasonable quality. Mainly because I can made meaningful tradeoffs to reach the quality goal. Nail all my feet to the floor, and I can’t move at all, and the Vorpal Duck comes and eats me.

6. Software Quality as variable constraint

I believe that tradeoffs between software quality and the variables of system scope, cost and schedule happen all the time. My typical goal is to make these tradeoff decisions as explicitly vs. implicitly. This requires reflection on the current situation and goals – as an individual and as a team. I believe that as system implementors, we represent the interests of our non-technical customers when developing the system. If we make tradeoffs by significantly lowering or raising quality, we should engage the customer in understanding the implications of the decision. Significantly lowering quality can cause the customer pain the future. Significantly raising quality can cause the customer possibly uneeded schedule or financial pain in the present. This now (d)evolves into a discussion of good enough software.

Elements of an Enterprise Software System

Enterprise software systems have some common elements. It is helpful to have a checklist of these common elements when designing, evaluating or even using such systems.

This is my checklist of common elements of enterprise software systems:

  • Data Entry
  • Collaboration
  • Workflow
  • Reporting
  • User Management
  • Billing/Invoicing/Collection
  • Instruction
  • Content Management
  • Syndication
  • Logging – Operational and Error
  • Monitoring
  • Notification
  • Audit trails

Quotes

“I’ve made peace somewhere between my ambition and my limitations.” – (from the movie, Teahouse of the August Moon.)

Getting it right the first time is not nearly as important as getting it right the second time.

Wide experience makes for deep tolerance.

It’s easier to pull down than to build up.

The most important events are often the results of accidents. (Polybius)

Action is the antidote for despair. (Joan Baez)

We cannot direct the wind, but we can adjust the sails. (Proverb)

The shortest way to do many things is to do one thing at once. (Samuel Smiles)

If you cannot feed a hundred people, then feed just one. (Mother Teresa)

Tell me and I’ll forget; show me and I may remember; involve me and I’ll understand. (Chinese proverb)

Sometimes you gotta create what you want to be a part of. (Geri Weitzman)

Ideas won’t keep; something must be done about them. (Alfred North Whitehead)

Do not let what you cannot do interfere with what you can do. (John Wooden)

The world stands aside to let anyone pass who knows where he is going. (Author unknown)

You don’t get to choose how you’re going to die. Or when. You can only decide how you’re going to live. Now. (Joan Baez)

The deepest principle in human nature is the craving to be appreciated and the desire to be important. (Dale Carnegie)

It is useless for us to reason a man out of a thing he has never been reasoned into. (Jonathan Swift)

Start with what you can do; don’t stop because of what you can’t do. (Author unknown)

Whatever you are, be a good one. (Abraham Lincoln)

If you think you can or you think you can’t, you’re right. (Henry Ford)

Be the change you want to see in the world. (Mahatma Gandhi)

Great wealth and contentment seldom live together. (Bob Phillips)

For every failure, there’s an alternative course of action. You just have to find it. When you come to a roadblock, take a detour. (Mary Kay Ash)

Have you got a problem? Do what you can where you are with what you’ve got. (Theodore Roosevelt)

Most people spend more time and energy going around problems than in trying to solve them. (Henry Ford)

When the only tool you own is a hammer, every problem begins to resemble a nail. (Abraham Maslow)

It is easier to do a job right than to explain why you didn’t. (Martin Van Buren)

“Only the ideas that we really live have any value.”
— Hermann Hesse. German novelist and poet, 1946 Nobel Prize for Literature, 1877-1962

Stockdale Principle – You have to be realistic bout your current situation and yet stay optimistic about the future.

Unlearning

Have you learned something new recently? If so – pat yourself on the back! Learning can be hard work.

But – have you ever unlearned something?

If you aren’t familiar with unlearning – I refer you to the popular “Mythbusters” TV show. I know many people who can’t get enough of this show. They look forward to it each week. I think it makes people feel good to be able to say “I know this isn’t true” – so they can forget about wondering if it was or not.

Plus – they Mythbuster crew likes to blow things up.  That’s always a good time!

I’m going to try to unlearn using underscores for private members in C#.

While this may sound trivial – I’ve felt need to change for several months – but it’s a habit that has crept into a couple of tools – and major chunks of recently delivered products.

Wish me luck!

Teams vs Teamwork

Been a member of a team recently? Ever? Are you sure? Do you know what a team is? Do you know the difference between an team and a group exercising teamwork skills? Have you ever wondered if the “team” you were in was really a team?

My purpose in this article is not to tell you how to form a team – but to help you recognize when you have a team and when you don’t. Too often managers think that they’ve got a team – when they don’t. They have not provided the necessary fuel for the team fire and in reality have a group of individuals executing teamwork skills.

These managers are disappointed in the performance of the “team” – and don’t understand why the “team” isn’t performing at a high performance rate. They may blame the members. They may blame themselves. They may blame their bosses.

Many people confuse the occurence of teamwork with actually having a team. Teamwork skills are readilly learned and easily identified by workers and managers. Some major teamwork skills include listening, questioning, persuading, respecting, helping, sharing and participating. These are all great skills to use in daily work to get things accomplished with other people.

A group of people exercising these skills are not necessarily a team. In fact, it is most likely just a group of people exercising teamwork skills individually.

What differentiates such a group from an actual team? This begs the question – what is a team? My favorite definition of a team is from Jeffery Katzenbach: “A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.”

Without purpose, goals and approach – you have a group of people. Getting people to commit to purpose, goals and approach are the elements that forge a team. Teams don’t last forever – they last as long as they are needed. Once purpose, goals and approach are no longer binding a team together – it dissolves into a group.

The reality is – maybe there is no need for a team.

Not all projects require a team. Some projects require a group of people to commit to individual goals – and reasonable results will occur.

Trying to get team behaviour out of a group that does not need to be a team will only frustrate the members and waste the leader’s time.

You do not have a team when:
1) Members say “Yes” all the time
2) No one raises objections to taking shortcuts on quality
3) Members are not concerned about schedule
4) Members follow managerial direction without improvements or questions – to avoid risk of responsibility for those changes – playing it safe
5) Managers/leaders focus on superficial aspects of teamwork (e.g. getting along, working overtime, being positive, working hard) instead of the core aspects (purpose, goals, approach)
6) Members don’t talk with one another about progress
7) Leader does not talk informally with members on a regular and frequent basis