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...
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.
Brief Introduction to Personal Planning
As a knowledge worker, you live in a world where a continuous stream of commitments are made and accepted 'round the clock. To succeed in this world, you must learn to make commitments and keep commitments. Since commitments that rest on a plan are more likely to be kept, you must learn to make plans quickly for your work and then carry out those plans effectively.
Software Development Strategy
The dictionary definition points us in the right direction. The software development strategy is your highest level plan for achieving your software project's objectives. According to Watts Humphrey, the strategy is "the order in which product functions features or requirements are defined, designed, implemented, and tested."
Effective On-Task Time
Software development is knowledge work. We use knowledge, take input as knowledge, and the output we produce is knowledge. Our output is executable knowledge. According to Peter Drucker, the 21st century's defining characteristic is knowledge work. We, software engineers, are in the thick of things.
Build a Rough Plan for Your Work
People who have not had to do any planning are stumped when asked to make a plan. I found that planning can be intimidating until you start with writing down what are the deliverables and what is the time frame. This will get your thinking started in the right direction.
Agile & CMMI & me
Back in the second half of the eighties I have been using some agile practices, but we didn't call it agile back then. We regularly pair programmed because my friend and I shared one computer; neither of us wanted to just sit and do nothing. Our workflow also included writing test programs (much like unit tests today).
The "One Right Process"
This week at Agile Austin the conversation veered toward a familiar topic: each problem is different therefore we cannot apply the same process to them. We, software developers, want to believe this. Why? Because this can be used as a convenient excuse: we don't have to follow a process if all problems are different. After all, we are on a quest to find the one true process that fits all programming problems, right?
What’s So Hard About Planning?
In the software business where most people don't seem to agree on anything it seems that everybody agrees that planning is hard. (The only thing that seems to be even harder is tracking to the plan and regularly replanning, but that's another story.)
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?
Getting Started with Software Reviews
The purpose of the design and code reviews is to find defects. The factor that most influences the length of a design or code review is the amount of work product that has to be reviewed. Checklist-directed reviews are the most effective at finding defects specific to the project and product, but not any checklist will do.
Guildelines for Detailed Planning
Business and society operates on commitments. For your commitments to be more than just empty statements, you must base those commitments on a plan of action. Creating plans is activity that can be learned. It takes practice to become good at planning.
Multilevel Planning
Even the smallest projects have multiple constituents. For each type of constituent, there has to be a plan that talks to their concerns. Some of the plans may overlap, however, other than milestones, you don’t want to duplicate information across the plans.
Software Process: Here is why I got interested
You know the feeling: you are assigned to a new project and asked to give an “estimate” of the length of time the new project will take. You think about it for a moment—or for a day—and then give the date. But you have no confidence in the date, so before you give it you double it, or triple it, hoping that the new date will give you just enough time to take care of most of the unexpected things that might come up.