Posts in the “best-practices” category

One thing a business analyst should ask about any requirement

As a business analyst (or any person interested in writing software requirements and quality), there is one thing you should always ask yourself whenever you write a business requirement:

Is this software requirement testable?

I’ve seen some business analysts write some crazy things and call them requirements, but IMHO, if you can’t test it, it’s not a requirement.

Business Analyst: How to write accurate software requirements

When you're working as a business analyst, the words you write are what you get paid for. Just like the author of a book, when you write software requirements, you shouldn't be loose with the words you write.

While working on a recent project, I started thinking about software requirements again, and was reminded how vague a requirement can be, even when you think it's well written. What made me think about this today was running across this performance requirement I found in an a requirements specification:

A simple software process review saves time

A few days ago I sat down and talked to myself (you can do that a lot in a small cabin in Alaska) and tried to think if there were any ways I could be more productive.

The biggest thing that was bothering me (the problem statement) was the time it takes after I've "finished" writing a long, multi-page tutorial before it can be published. I prefer writing longer tutorials, but they do take a fair amount of effort.

Continuous integration software development best practice

Continuous integration is a key to a quality build process for any multi-developer software development project. I can't say it much better than the way Martin Fowler describes it, so I'll just include a portion of his summary here:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day.

Software code coverage and automated testing

I started using a tool named Cobertura to generate code coverage reports lately, and I have to say that I've been very happy with the results. If you are a believer in test driven development, or TDD, the next step in the process is code coverage.

Unit tests - documentation you can compile

In the category of best practices I have to include my thoughts today on unit tests as a form of "comments/documentation you can compile". Let me explain:

I recently had the experience of (a) working on a small but complicated software development project, (b) leaving that project for six months, and then (c) being asked to work on it again. All I can say it wow -- what a great experience it was to come back to a project that was loaded with unit and code coverage tests.

Meditation leads to concentration

In other blog posts I've mentioned that I think meditation can be a great tool for improving your concentration, so I thought I'd take a few moments here to explain how to meditate. It comes very naturally to me these days, but if you've never meditated before you may not know how to get started, so I thought I'd share this very simple technique here.

Ways to improve your brain power

Recently I wrote an article about using meditation to improve your concentration and brain power. Today I'd like to briefly outline a few other ways you can help improve your brainpower.

Use your off hand

You've probably heard about this already, but if you're right-handed, learn to use your left hand. Brush your teeth with your other hand, write with your other hand, basically reverse everything in your life as your hands go. You'll be amazed at the difference.

If you could see bad code it would look like this

I was talking with a friend the other day about what bad software code ("smelly code") looks like, but I found it very frustrating. I ran into that a lot in my consulting career; it's hard to describe to a non-technical Project Sponsor or Project Manager why their existing code er ... isn't in great shape.

After that discussion, my friend -- who is an engineer and former electrician -- forwarded the following pictures to me, and asked if this is what smelly code looks like. I could only laugh and say yes, that is exactly what it looks like.

Apple's Tim Cook on quality versus revenue

Summary: This article shares a quote from Apple’s Tim Cook about products, quality, and revenue, and how it might help your business to think the same way.

I don’t remember exactly where I read the following quote from Tim Cook of Apple (it may have been at AppleInsider), but I made a note of it, and just ran across it again:

Software requirements writing - two notes on my frame of mind

Here are a couple of notes I just sent someone on how to get started writing a software requirements specification.

They may be a little vague, but I hope they show my intent, or perhaps my frame of mind, when writing a software specification.

Fred,

Here are two notes on my mental approach when writing software requirements specifications:

Function Point Analysis presentations online

I've had some Function Point Analysis documents available here before, and recently finished converting those presentations into a better form for the internet. To that end I've gathered all these in a new Function Point Analysis Education Center, which contains those free documents and presentations.

These educational documents cover FPA, cost estimating, and even cost estimating for Agile software development projects.

Sophocles: One learns by doing the thing

I was reading Dr. Dobbs last night, and they referenced this story about how quantity ends up producing quality, at least when it comes to humans creating things.

The lesson goes like this: A ceramics teacher divides a class into two teams, then tells one team they'll be graded by sheer quantity, while the other side has to produce one great pot. In the end the Quantity Team delivers all the best quality pots.

I've found this to be true with new programmers. All newbies want to learn about things like design patterns, but what they really need to do is just sit down and write a lot of code.

This reminds me of the quote, "One learns by doing the thing." I don't know for sure who said that — possibly Sophocles — but I remember reading it in a Thermodynamics book in college, and I've never forgotten it.

An IKIWISI story

For developers frustrated with end users suffering from IKIWISI ("I'll know it when I see it"), let me share this story with you.

Rule number one for software project managers

Here's my Rule #1 for Project Managers, as looked at from the perspective of a software developer:

Show active interest in your project, and in the people that work on the project.

Okay, I know that seems obvious -- and I'm a little fired up about this right now -- but I've been amazed to work with project managers in the last few years who seem to have more important things to do outside of work than they have to do at work, and by this I only mean during the Monday through Friday, 8-to-5 time frame.

Basic software development best practices

Software development best practices FAQ: Can you share some "software development best practices" you learned as the owner of a computer programming consulting firm?

Sorry, I don't have a lot of time for discussion today, but here's a brief list of the most important "software development best practices" I know, both for a software development organization, and your personal programming career:

Software metrics: A Tufte-inspired graph for software development projects

I couldn't sleep last night so I started reading Edward Tufte's "The Visual Display of Quantitative Information", and I started thinking about software project metrics that might be useful to the team members on a software development project (including developers, business analysts, domain experts, and stakeholders), and how I would show these metrics in simple but data-filled Tufte charts and graphs.