Wednesday, 23 February 2011

Dealing with Complexity

==========
Code Complete (Steve McConnell)
- Highlight Loc. 5564-67  | Added on Thursday, February 17, 2011, 06:28 AM

Reduce complexity. The single most important reason to create a class is to reduce a program's complexity. Create a class to hide information so that you won't need to think about it. Sure, you'll need to think about it when you write the class. But after it's written, you should be able to forget the details and use the class without any knowledge of its internal workings.
==========

Code Complete (Steve McConnell)
- Highlight Loc. 5871-76  | Added on Thursday, February 17, 2011, 06:43 AM

Reduce complexity. The single most important reason to create a routine is to reduce a program's complexity. Create a routine to hide information so that you won't need to think about it. Sure, you'll need to think about it when you write the routine. But after it's written, you should be able to forget the details and use the routine without any knowledge of its internal workings. Other reasons to create routines—minimizing code size, improving maintainability, and improving correctness—are also good reasons, but without the abstractive power of routines, complex programs would be impossible to manage intellectually.

==========

And not just classes. If you find complexity anywhere in a software system, find a way to modularize it and hide the complexity away.

Monday, 21 February 2011

Abstracting

==========
Code Complete (Steve McConnell)
- Highlight Loc. 5558-63  | Added on Thursday, February 17, 2011, 06:27 AM

On programming projects, the abstractions are not ready-made the way Shape is, so we have to work harder to come up with clean abstractions. The process of distilling abstract concepts from real-world entities is non-deterministic, and different designers will abstract out different generalities. If we didn't know about geometric shapes like circles, squares and triangles, for example, we might come up with more unusual shapes like squash shape, rutabaga shape, and Pontiac Aztek shape. Coming up with appropriate abstract objects is one of the major challenges in object-oriented design.
==========

Your abstractions need to model the domain accurately. I worked on a project where the abstractions didn't model the domain correctly, and it caused us terrible problems. It was a blotter application used in a bank for Credit Default Swaps. When we added new functionality to handle unwinds, we didn't understand that an unwind was an event on an existing deal. In our abstraction, we modelled the unwind as a separate deal.

As we came to understand the business better we realized that we had painted ourselves into a corner. It made adding new functionality incredibly frustrating and difficult, with really convoluted code required to bridge the gap between our model and reality.

If your map doesn't accurately represent the territory, you will either take longer to reach your destination, or lose your way entirely.

Saturday, 19 February 2011

Beautiful Code

==========
Code Complete (Steve McConnell)
- Highlight Loc. 3303-7  | Added on Monday, February 14, 2011, 07:55 AM

When I am working on a problem I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong. — R. Buckminster Fuller
==========

Programming into a Language

==========
Code Complete (Steve McConnell)
- Highlight Loc. 3021-31  | Added on Monday, February 14, 2011, 07:41 AM

Visual Basic didn't support this convention directly, but my use of a simple programming convention—programming into the language—made up for the language's lack of structure at that time and helped keep the project intellectually manageable. Understanding the distinction between programming in a language and programming into one is critical to understanding this book. Most of the important programming principles depend not on specific languages but on the way you use them. If your language lacks constructs that you want to use or is prone to other kinds of problems, try to compensate for them. Invent your own coding conventions, standards, class libraries, and other augmentations.
==========

Programming into your language, according to McConnell, means not limiting your thinking only to the concepts automatically supported by the language. Instead, think about what you want to achieve and how you want to achieve and then, if your language doesn't automatically support that way of working, define conventions that you will use to meet your objectives.

This is a powerful concept, and something that every software craftsman should strive for. It's about personal discipline. Everyone knows that it's possible to write really hairy Perl code. It's also possible to write really beautiful Perl code.

Clojure Complete

==========
Code Complete (Steve McConnell)
- Highlight Loc. 2851-56  | Added on Monday, February 14, 2011, 07:30 AM

In the case of natural languages, the linguists Sapir and Whorf hypothesize a relationship between the expressive power of a language and the ability to think certain thoughts. The Sapir-Whorf hypothesis says that your ability to think a thought depends on knowing words capable of expressing the thought. If you don't know the words, you can't express the thought and you might not even be able to formulate it (Whorf 1956). Programmers may be similarly influenced by their languages. The words available in a programming language for expressing your programming thoughts certainly determine how you express your thoughts and might even determine what thoughts you can express.
==========
Code Complete (Steve McConnell)
- Note Loc. 2855  | Added on Monday, February 14, 2011, 07:31 AM

think about clojure in relation to this. you define your own language.
==========

Top of my list for personal development this year is to re-visit Clojure. Although I spent a few months programming in it last year, I have the nagging suspicion that I was actually programming in Java in Clojure. I want to learn to think in Clojure, and program in it idiomatically.

This quote from Code Complete caught my attention because of the idea that in Clojure you write the language that you want to write your application in. Clojure is, in many ways, the ultimate language for writing a DSL, since there is minimal syntax and thus any functions and macros you write in effect extend the language. You are not limited to the words provided by Clojure - you can invent new words to express your thoughts.

This is the sort of thing that I want to investigate further.

I am very hopeful that the upcoming Joy of Clojure will help me to attain Clojure enlightenment.

Apprenticeship Patterns

==========
Apprenticeship Patterns (Dave Hoover and  Adewale Oshineye)
- Highlight Loc. 668-70  | Added on Friday, January 28, 2011, 07:03 AM

The journeyman is focused on building an ever-larger portfolio of applications that demonstrates his progress in the craft; he moves between projects and masters, seeking to diversify and deepen his portfolio; he seeks to elevate his status within the community; and he strives to become ready to be a master.
==========
Apprenticeship Patterns (Dave Hoover and  Adewale Oshineye)
- Highlight Loc. 1184-86  | Added on Friday, January 28, 2011, 07:44 AM

Take the list of items from Expose Your Ignorance and strive to learn each one, crossing them off the list as you do so. This new knowledge you have may reveal gaps you hadn’t noticed before; don’t forget to add these things to your list.
==========

I enjoyed reading Apprenticeship Patterns more than I thought I would. It provides some really great advice on how to progress in a career in IT, with a particular focus on ultimately becoming a software craftsman.