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:

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.

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:

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.

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.

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.

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.

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 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:

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.

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.

The magic of deadlines (Software best practices)

Wow, I've been reminded lately how important deadlines are.

I've been working on this website all summer, but at a moderate pace. Then recently I put together some goals for the end of the year, which, in turn, led to other short-term goals. Now, it turns out that my short term goals are hard to meet, but not impossible.

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.