Pondering about programming

Sometimes it is good to take some distance from what you're doing, so you can set your priorities for the near future.

Wat is programming, actually?

Seems to be a silly question, because you'd think that programming is about producing code, but it's not.

I suggest you read Teach Yourself Programming in Ten Years, by Peter Norvig. Most noteworthy programs are written as team efforts, and if you want to become a good programmer, you need to be able to work in a team, sometimes as an experienced leader and sometimes as a novice to the software project (in order to give orders, you have to be able to follow orders as well).

A good programmer has good interpersonal skills and can work in teams. Interactions between programmers are perhaps more important than the code they write.

Writing good code should be the goal

Unfortunately, the coding community has the reputation of writing bad, bug-ridden code, that needs constant updating and lots of support to and feedback from the end-users (which explains why good customer support is such a large chuck in the total costs of software development). Also, people tend to own a part of a project, do poor documentation, then run away from projects and leave the team with undocumented, buggy code, which has to be fixed by other people. There are a lot of bad coding teams out there. Not necessarily because the team members are bad coders, but because the team's organization, well um, sucks.

So how to spot good coding practices? Read The Joel Test: 12 Steps to Better Code and learn.

Software Development Process

I haven't considered that there are different methods to develop software, especially if it is done in collaboration.

I have five interesting Wikipedia entries I should read and digest (entry summaries taken from Wikipedia):

Software development process

A software development process is a structure imposed on the development of a software product. Synonyms include software lifecycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.

Waterfall model

The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. The origin of the term "waterfall" is often cited to be an article published in 1970 by W. W. Royce; ironically, Royce himself advocated an iterative approach to software development and did not even use the term "waterfall". Royce originally described what is now known as the waterfall model as an example of a method that he argued "is risky and invites failure".

Iterative and incremental development

Iterative and Incremental development is a software development process developed in response to the weaknesses of the more traditional waterfall model. The two most well known iterative development frameworks are the Rational Unified Process and the Dynamic Systems Development Method. Iterative and incremental development is also an essential part of Extreme Programming and all other agile software development frameworks.

Agile software development

Agile software development is a conceptual framework for undertaking software engineering projects.

There are a number of agile software development methods, such as those espoused by The Agile Alliance. Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. In many cases, software is released at the end of each iteration. This is particuarly true when the software is web-based and can be released easily. Regardless, at the end of each iteration, the team reevaluates project priorities.

Agile methods emphasize realtime communication, preferably face-to-face, over written documents. Most agile teams are located in a bullpen and include all the people necessary to finish software. At a minimum, this includes programmers and their "customers" (customers are the people who define the product; they may be product managers, business analysts, or actual customers). The bullpen may also include testers, interaction designers, technical writers, and managers.

Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.

Formal methods

In computer science and software engineering, formal methods are mathematically-based techniques for the specification, development and verification of software and hardware systems. The use of formal methods for software and hardware design is motivated by the expectation that, as in other engineering disciplines, performing appropriate mathematical analyses can contribute to the reliability and robustness of a design. However, the high cost of using formal methods means that they are usually only used in the development of high-integrity systems, where safety or security is important.

Of course, there are many more articles to read on this subject. There is a list on Wikipedia of all entries about the Software Development Process.

After listening to the Cincon Smalltalk podcast series (of which most episodes have Industry Misinterpretations in their title), episode Industry Misinterpretations Episode 23: Retrospective Coherence (MP3 file), I came to the conclusion that this topic, the software development process, is a really interesting.

Some fun and interesting paraphrases from that podcast episode:

Most people hear to listen, not to understand, like they have read-only memory

in order for a complex system to have resilience, it has to have some degree of inefficiency

process and code optimization should always be the last step in development, otherwise the system loses it's flexibility and ultimately breaks down

the purpose of most meetings is to keep people from taking responsibility

And then there are many more profound notions in this episode. Be sure to listen, but be warned that the audio quality is a bit poor.