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.
Posts in the “best-practices” category
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.
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:
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.
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 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.
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.
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.
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 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.
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:
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.
Here's a little Java best practics info from someone named Ahmet Haliloglu. It's mostly on servlets and JDBC.
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.
Here are two notes on my mental approach when writing software requirements specifications:
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.
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.