Posts in the “best-practices” category

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.”

One Java programming "best practice" that has been strongly reinforced for me during the last several weeks is making sure you have a declared interface that defines the behavior (signature) of your Dao (data access objects) classes.

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:

I'm sure this will sound strange to some people who know me, but I was happy to stumble on several Eclipse user interface design documents yesterday, including their UI Best Practices, User Interface Guidelines, and Top Ten Lists Working Page documents.

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.

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.

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:

One of my beliefs regarding you and your career in the software industry is that you need to understand your strengths and weaknesses, and improve both.

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.

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.

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

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.

Over time I hope to write more posts about software cost estimating, but for today I just want to list some of the software cost estimating variables from the model of the Cocomo II software application:

Here's a little Java best practics info from someone named Ahmet Haliloglu. It's mostly on servlets and JDBC.

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.

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:

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:

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.

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