Tag Archives: Software Development

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.1 As a software professional you can improve the odds of being successful right from the start if you are prepared for your first day.

During the upcoming months I’ll publish articles about practical knowledge and useful tools needed for starting out in a software development career. As a recent computer science or software engineering graduate starting your first job after graduation—or even as an intern working through your first programming internship—you might find these articles useful.

Your professors taught you many wonderful and useful things in school. When you get to your first job there are many more things that a company assumes that you’d know, but nobody tells you about them during your school years. I’ll touch on five broad areas to help you prepare and improve your odds of success beginning with your first assignment.

The opening article will target the essential tools that cut across all roles for anyone doing knowledge work in today’s office environment. Next, I will write about the professional relationships in an office, including working on cross-functional teams.

What follows the more general knowledge worker topics are articles about some of the specific knowledge needed from computer science and from software engineering perspective. Lastly, I will close with an article about the tools required to do a competent software development job in 2016.

The series on Starting in a Software Development Career

  1. Office Worker Essentials
  2. Your Professional Relationship with your Colleagues
  3. Computer Science Essentials for the Working Software Developer
  4. Software Engineering Essentials for the Working Software Developer
  5. Master Your Software Development Tools

__________
1. What constitutes results is a large and opinionated topic that will be the subject for another day.

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.

Even the Romans knew that “verba volant, scripta manent,” meaning “the spoken words fly away, written words remain.” So maybe the real question is not “Should we write anything down?” but rather “How much should we write down?” The face-to-face interaction should be followed up with the creation of an artifact that captures what the conversation clarified. This will serve as the basis for further decisions or conversations, or maybe assists in the reexamination of this decision when more data becomes available. Interspersing face-to-face conversations with written thoughts firms up ideas and speeds up the road to shared understanding and clarity.

Usually at this point somebody will jump in to say that all that writing is taking time and that writing a 100-page requirement or design document is a waste. Yes, 100 pages might be a waste most of the time. I think that the artifact produced should be a piece of focused and processed information. If it is 100 pages then it should be indeed a very complex issue, or somebody hasn’t done enough thinking about this. But I’ll leave this topic for another day.

This belief in writing things down was confirmed a few weeks ago as I talked to a new co-worker, Steve Feldman, who writes the Seven Seconds blog. He mentioned that he routinely asks his dev teams to blog about their work. The part of the work that is general in nature can be blogged on their outside blogs, while the company and product specific work should be blogged on the inside blogs. The act of writing things down externalizes the person’s thinking and opens up the ideas for a conversation with the rest of the team.

The blog entry with one’s thoughts will generate further conversation, both online and face-to-face. Each conversation should bring the team closer to identifying and solving the problem that they have set out solve.

Software Development Strategy

, ,

strat-e-gy: a plan of action or policy designed to achieve a major or overall aim.

The New Oxford American Dictionary

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.”

What does this mean? This means that the plan of action part of your strategy lays out what you build first, what you build next, and so on. It also lays out how are you going to validate the strategy. The strategy also lays out the policies for risk mitigation and decision making. Sections of the strategy may exists both along the developer – customer continuum and also along the system abstraction levels continuum. For details about these continuums see: Multilevel Planning and Component-Based Development.

The System Architect is responsible for the overall strategy. The strategy has to be sound enough that designers and implementors working on parts of the system receive from it the necessary guidance to aid their technical decisions. A well conceived strategy pushes the decision making down to the lowest possible level, closest to where the problems are encountered, while at the same time provides for the oversight necessary to build a coherent system.

Accompanying the development strategy is the testing strategy. The testing strategy focuses on the various testing activities, including the system validation and verification activities. It is constructed similarly and serves the same purpose as the development strategy, only for testing. The owner of the testing strategy may be the System Test Architect, if there is one, otherwise this is also owned by the System Architect.

Why do you need a strategy? Without a strategy it is difficult, if not impossible, to execute an iterative, incremental development process. The strategy ties the iterations into a coherent whole, and allows the team to move confidently toward the goal. Your first attempt at creating a strategy may feel awkward, but with practice you’ll get better at it. Why don’t you get started today?

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:

  1. Static Structure Diagram: this is a class, module, or package diagram. This diagram (though often it is more than one), shows the relationship between parts of the system at a given level of abstraction. The relationships shown include: containment, references, parameters, inheritance, and so on. Record on the diagram indirect and implied dependencies with a note.
  2. Initialization Sequence Diagram: shows how the system is brought up from being on the disk into the operative memory and “ready to transact business” state. This diagram is part of the dynamic model of the system. It shows the order of messages sent or method invocations. Often also shows resources allocated to get up and running.
  3. Shutdown Sequence Diagram: shows how to put back the system or component into the proverbial “bit bucket.” Must complement the initialization sequence diagram and demonstrate that the system is not loosing resources during its operation.
  4. Sequence Diagrams, Activity, and/or State Diagrams for the key “business” of the system or software part. All other activities took place just to get ready to do the business of the system. Now it is time to get the business done. The key sequence diagrams show what the system does, how it provides the value that it is expected to deliver.
  5. Brief Design Commentary to explain the “why” behind key structural and behavioral elements and decisions. This is usually one Wiki page that ties all other documents together into a coherent whole.

Each of these can be created at “every zoom level” in the system. This means that if you are developing a component-based system, then you would have this set of design documents for the system, subsystems, modules, and components. Within each you represent the unique concerns of each software part.

Read Applying UML and Patterns, 3rd. Ed., by Craig Larman for an in-depth course on how to do object-oriented analysis and design on an iterative software development project. As you do design more, review your results, learn from your mistakes, and over time you’ll get better at it.

Resources:

  1. UML basics: An introduction to the Unified Modeling Language, from IBM developerWorks, 2003.
  2. Allen Holub’s UML Quick Reference. 2007.
  3. Book excerpt from OOAD with Applications, by Grady Booch.
  4. UML Modeling in Color, from Wikipedia.

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.

  1. When did the project start? This is the Start Date.
  2. When is the project expected to end? This is the Expected, Planned, or Estimated End Date.
  3. Where should we be today based on the plan? This is the Expected, Planned, or Estimated % Complete.
  4. Where are we today? This is the Actual % Complete.

If you have the above information then you are able to judge how well you are doing relative to what you said you’d be doing. There is a lot more to project management, but this is a good start.

To get started make a plan for the work you intend to do this week. Write down at least 2 tasks for each day: one task for the morning, one task for the afternoon. This gives you a total of 10 tasks for the week. As you check off the completed tasks, you’ll see your progress bar move. Once you are able to plan your work for a week, plan the next month. Collect your data and adjust.

There is no need for you to wait for your entire organization or team to start doing this. You can get started alone. You’ll be surprised how much better your work will go and how much better you’ll be able to help your team.