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.
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.
The Essence of Knowledge Work, Part 1
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. This looks like the information processing business.
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.
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.
Resources for a New Manager
The life of a new manager is full of challenges. You, like many people before you, might've gotten into this role without any management training. This article aims to assist you in building your own management curriculum to help you on your new journey.
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.
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?
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!
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.)
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?
IEMC '07
The 2007 International Engineering Management Conference was held near Austin, at Hyatt Lost Pines Resort from July 30 through August 1. I was a panelist on the Peter Drucker Leadership Panel.
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...
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.
Samsung's Way of Innovation
The July 3, 2006 issue of Business Week has a story on how innovation happens at Samsung. Samsung created a Value Innovation Program and have identified key brainstorming practices.
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.
Managers Need Tools
It seems that all professionals have their tools, but somehow managers were forgotten. No more! There is a great podcast to provide the tools that managers need to do their jobs better called Manager Tools.
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.
Killer Innovations
If you don't yet know who Phil McKinney is, then you need to look him up. More importantly, you need to listen to his podcast, Killer Innovations. Phil's insight into the innovation process provides you with knowledge you can use in your daily work.
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.
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...
Do you use your brain at work?
You probably have to. Knowledge workers today make up over 70% of the working population. Your productivity is your competitive advantage! Take charge of you future! Discover what makes you more productive, and put yourself on a trajectory for greater success.
Thoughts on Performance
You are a software developer. You are good, and you know it. Maybe in the top 10%. But, do you know how good you are? Do you understand why you are so good?
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 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...
The Apollo Guidance Computer
At times of stress and sorrow I tend to look back and attempt put things in perspective. I can't find anything that would put what has happened last week in any perspective.
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.
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.
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.
Open Letter
Our profession is still relatively young. The field of software development seems like a mine field--without a comprehensive map--to many practicing software engineers. The information that you find here will provide insight to make your day-to-day work more effective and more enjoyable.
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."
Version Numbers
A version number is composed of the following four fields: major.minor.revision.build. By itself a version number is not all that meaningful. The version number is only valuable to denote change. Here is a way to make sense of version numbers and to use them effectively.
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.
Privacy Policy
We do not sell, trade, or otherwise transfer your personal information to outside parties. This statement does not cover the third parties who assist us in operating our website, conducting our business, or servicing you. Please consult their privacy policies for details.
Talks
Talks about software development principles & practices, software process, the people of software, software project management, and software as art and science.