Two Rectangles: A Prototype Story
Prototyping is often under-appreciated. Something as simple as printing two rectangles printed on a page can prove that it is worth embarking on a 7 month development journey because the product you need to build can be built.
The Simplest Interview Question
Sometimes the simplest questions are the hardest to answer. That is the case with this one. Even this simple question allows us to talk about a wide variety of computer science topics.
Embracing Simplicity
Markdown parsers have evolved. You can edit your content in markdown and generate not only beautifully rendered text from it, but also syntax highlighted code, math formulas, software diagrams, and even use emoji short codes.
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.
Your Professional Relationship With Your Colleagues
In some places software development is still regarded as a highly technical activity performed by a lone genius programmer writing fantastic code. That’s not quite the case anymore. While an individual can still write great programs alone, most programs require more than one developer. Software development has increasingly become a cross-functional team activity. Your ability to work with your colleagues has become a critical aspect of your success as a knowledge worker.
Starting in a Software Development Career
In our competitive world people are expected to produce results beginning with the first day on the job. The guidance you get about what constitutes results is usually not as clear as we all wish it would be. As a software professional you can improve the odds of being successful right from the start if you are prepared for your first day.
Planning for Developers from Knowledge Worker Perspective
Planning is a controversial topic in software development. There is a feeling that we, software people, we don’t want to plan at all. The outsiders might have a point. Even though lack of planning arguably makes our lives harder than it should be we still don’t want to plan. There are steps you can take to get past these preconceptions and derive immediate benefits. Read more to find out how.
Writing Crystallizes The Thought
Agile Teams often hold the belief that we should not write anything down because that's waste. From a human perspective though we need to write things down because that's the mechanism that allows us, or maybe even forces us, to think things through.
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."
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...
What's the Status?
Regardless of the organization you work in, this question probably comes up daily, but at least weekly. To answer the often dreaded status question you need minimum 4 pieces of information.
Knowledge You Expect To Learn
Writing an individual project plan for your project work can be difficult. The secret of creating a workable task plan is to consider not only the work you will complete, but also the knowledge you expect to learn as you perform each task.
Humans, Multitasking, and Context Switching
The modern age demands from all of us to deliver more in shorter time. The easy solution to this problem is to multitask. However, as an article by Roger Brown points out: 'Multitasking Gets You There Later.' At the bottom of the article he provides a good list of references as well.
What Makes a Good Wiki Page?
Groups large and small use Wikis to capture and share knowledge. As you read page after page of a Wiki, you notice that some pages are good, but others not so much. What traits distinguish a good Wiki page from its mediocre cousins? Here are the four key factors that make a Wiki page good.
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.
Understanding a Software System
The need to understand a software system comes up many times during the career of a software professional. A common situation is that you have just been assigned to a new software project. You'll be working on a system that is unknown to you. Your first task is to fix a defect. Where do you start?
Mastering Deadlines
In Living with Constraints, I touched on a topic that is on the mind of software people: managers and developers alike. The time constraint, also known as The Deadline, is of particular angst for some technical people.
What Makes a Good Wiki?
You heard of Wikis. You might be using them daily. They are everywhere you look. Unfortunately, quite a few of them are not as useful as they could be. Over the years many of them became dumping grounds for page after page. How can you make your Wiki work better for your group of collaborators? Make the Wiki tell a story!
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.
Version Numbers and Component-Based Software Development
Component-Based Software Development is a topic I return to from time to time. It is almost ancient history now: it was in 1993 when Microsoft came out with OLE (Object Linking and Embedding). OLE was based on a simple premise: a component can ask another component a simple question: "Do you support interface X?"
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?
Peter Drucker on Software Management
Well, Peter Drucker didn't write about software management, but he did write about management. In his book Managing in a Time of Great Change he has a chapter called The Five Deadly Business Sins. Here is what Drucker has to say...
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.
Metrics Shmetrics!
The Austin Software Process Improvement Network meeting I attended tonight was a roundtable on metrics. As I was listening to the panelists explain their experience and ideas about measurement, it occurred to me that most people harbor some basic fears about measurement. Here are some ideas about how we can these nagging fears...
Context
Most programmers know about "context switch" if their education or experience included at least some amount of assembly level work. In the "context" of assembly programming context refers to the contents of all CPU registers.
What are you going to do?
One of my longtime favorite software gurus, Larry Constantine, gave a keynote presentation at Software Development 2001 conference in San Jose earlier this year. Here is the last slide from his talk...
Common Sense
Steve McConnell is one of the most practical software guys that I am aware of. In the recent issue of IEEE Software, he wrote an editorial entitled Common Sense.
Research vs. Development
Arguing whether or not some work is research or development is all too common on software projects, especially in Software Research & Development (R&D) organizations. On many projects developers tend to declare a large part of the work as "research" and decide not to create any plans for it, postulating that "it is impossible to plan research."