Posts in the “best-practices” category

The “reduce, reduce, reduce” mantra applied to writing

One philosophy I have about writing technical material is that I want to condense the material as much as possible, to the point where I want people who use yellow highlighters to mark most of what I write. I am one of those people who use yellow highlighters, and I look for that property in books that I read.

This isn’t necessarily true for blog posts that I write, because for these I usually write them pretty fast. But for books, I take the time to review them and look for this quality. This follows the design mantra, “reduce, reduce, reduce.”

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.

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:

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.

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.

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.

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.

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.

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.

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:

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.

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.