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.
Office Worker Essentials
A century ago the majority of people were employed in manual labor: either on a farm or in industry. A small minority worked as professionals. They were the early knowledge workers. Their primary tools were the pen and paper. How times have changed. Today every knowledge worker has a myriad of tools at their disposal and they are expected to master them.
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.
The Essence of Knowledge Work, Part 3
Knowledge workers take in information, process it by applying their knowledge to it, and output information (possibly) in a different format than they received it. You, like many other knowledge workers, produce your output artifacts by applying knowledge to the input you receive. Your knowledge includes everything you know and the input you receive from all possible sources, too.
The Essence of Knowledge Work, Part 2
Your information supply chain consists of all artifacts that you consume (produced by your colleagues) and the artifacts that you produce (consumed by your colleagues). You produce your output artifacts by applying knowledge to the input you receive. Your knowledge includes everything you know and the input you receive from all possible sources.
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."
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...
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.
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.
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?
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!
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).
Setup a Website for Your Organization
If you are part of a volunteer organization, you know that the organization needs a website. You may also know that it is difficult to find a webmaster for the group. Most folks don't know HTML, so you need a website that anybody can edit through a browser. Here is how you can set one up quickly for very little money and without much technical knowledge.
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.)
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?
Elements of Agility: Levels of Initiative
When agility comes up in conversations, the typical topics are methods, techniques, or process, but rarely _initiative_. Even though initiative, more than other factors, determines if a team can perform at maximum performance. These days an organization cannot be competitive if its people are at levels 1 or 2 on the initiative scale.
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.
Innovation Happens In Unexpected Areas
One of the many interesting stories from They Made America: Two Centuries of Innovators from the Steam Engine to the Search Engine, by Sir Harold Evans is the story of Samuel Insull. His innovation was in pricing. He worked on understanding how his customers would use electricity, and then devised a pricing method to meet the estimated need.
How I Got Started With Management
It must be an inner drive that I like to see things done, and that I have taken up interest in getting things done from an early age. As far as I remember, I have always headed a little group and worked on some sort of project that I wanted to see completed, preferebly sooner, then later. I have a natural inclination toward leadership. Several groups have appointed me to become their leader, and I took up leadership positions on my own.
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.
Why Focus On Software Development Performance?
As software permeates every aspect of our daily lives, more software is needed to support our societyโs ever increasing needs. For the manager or executive overseeing software-heavy projects: it is easy to feel overwhelmed. Missed commitments, defective software releases, and almost never ending user satisfaction issues seem to be the norm...
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...
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...
Slack off
You say you don't have time to slack off? You are too busy? You have too many things to do? Think again. One of my favorite gurus decided to not slack off entirely, and he wrote a pretty good book on the subject. Read it the first chance you get: Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, by Tom DeMarco.
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."
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.
Welcome!
Welcome to Practical Software Engineering! Enjoy your visit. I created this site with the intent to become a resource for ideas and practical advice on software engineering for practicing software engineers. The ideas expressed here are my own and represent my views on software engineering and the engineers and managers that make software come alive.