Tests As Requirements for Design
If you ask anyone in the software industry if they do any software design, they will all say they do. When you ask them what artifacts do they create when they do software design they usually come up empty handed. Best case, someone will say that they make some sketches on a whiteboard and that’s their design. Ever wondered why...
Master Your Software Development Tools
Like all professionals, software developers built themselves tools, many software tools, to help them get their job done better. The chalkboard (replaced by the whiteboard), and paper & pencil have been with us from the very beginning. There are more tools now in the developer's toolbox, each serving a unique purpose in the software development life cycle. With each tool comes the need to learn how to use it, to become good at getting the work done with it.
Software Engineering Essentials for the Working Software Developer
The previous article in the series mentioned topics that are rarely if ever discussed in a Computer Science curriculum. The topics in this article are also often skipped. Unfortunately, the knowledge of these software engineering topics is quite important for a working software developer who has software to build and deadlines to meet.
Computer Science Essentials for the Working Software Developer
Some key nuggets of knowledge toward writing good code are either not taught in school or are mentioned as esoteric theoretical knowledge and most people don’t realize how practical and important they are for competent, everyday software development work. Building software from components, assigning responsibilities to components, deliberately deciding how state is stored, coupling, cohesion, and cyclomatic complexity are essential elements of good software practice.
Essential Software Design Documents
When it comes to documenting software designs, there are many practices ranging from a quick whiteboard sketch to fully specified UML models with OCL to tens of pages of written text. Here is what I found that worked best based on most projects that I have been part of...
More on Prototyping
To convert the unknowns into knowns, you need to aggressively prototype. To learn about the users, the technology, and the problem you must prototype.
Why Prototype?
Every once in a while I am surprised by somebody who says that prototyping is such a waste of time. For quite some time I have taken for granted that prototyping is a fact of my software engineering life. Maybe it is worth asking: what is the problem for which prototyping is the answer? Or, in other words: why should you prototype?
What do you know?
Why is it that most software developers have such a miserable track record when it comes to finishing projects on time and on budget? During my software career I met some of the smartest people around and still most of them were not able to finish projects by the date that they set.
Common Defects
A while back I had the opportunity to analyze a few defects up close. I saw some interesting types and I decided to write about them. Understanding the nature of your defects could prove to be useful for your day-to-day work. Most of the program defects that I have seen fall into one of the following categories...
Aspect-Oriented Programming
A few months ago I came across the concept of Aspect Oriented Programming or AOP. I thought that it was interesting. And I stored the information away... somewhere. The current issue of the Communications of the ACM features a series of articles on this topic.
Component-Based Software Development
Of the many ways that you can build software two are used most often: based on use cases (vertical slices of end-user functionality through the system) or layers (horizontal sets of related technical functionality). Either way, when done, you'll end up with a set of cooperating components that implement the system's business.