First Steps in Flex (Book Review)

So, I won this book by asking James Ward a good question during CodeMash2009. I'd already been working with Flex for quite a while, so I thought this book would be too basic for me. But since it was a concise 140pp., I sat down an gave it a read. Most of the stuff is pretty basic, but it also presents things with an opinion.

In Flex/Actionscript, you can implement the same behavior many different ways, but this book presents examples in the authors' preferred way. The book comes across with the development experience of the authors, which is the most valuable information. Some chapters were 1 page, because there wasn't much else they could say that wasn't in the documentation. And every chapter had a Further Learning section that provided references to specific topics.

I wish this book was around when I started playing with Flex.

The ThoughtWorks Anthology (Book Review)

I read this book from cover-to-cover while traveling home from the Bahamas (about 8 hours for 213pp.) The book is a collection of 13 essays, plus a intro written by a VP @ ThoughtWorks. Published by Pragmatic Programmers.

Solving the Business Software "Last Mile" -- Roy Singham and Michael Robinson
The last mile refers to problems encountered after functional requirements have been met, but before software is deployed and providing value. The first thing that comes to mind is non-functional requirements (NFR): system performance under different loads, capacity, security, etc. These NFRs become more significant and dangerous as systems mature because of the potential problems as new software is introduced into the existing environment. Each new piece of code can potentially alter the NFRs of the production environment. The solution starts with automating the testing of NFRs. This requires communication with people about NFRs up-front and continuously updated, so that tests can be updated. Also, keeping tests independent of wall clock time, since this changes from environment to environment. Using counter-based tests instead of time-based tests.

One Lair and Twenty Ruby DSLs -- Martin Fowler
This essay iteratively explores multiple approaches to producing an example internal domain-specific language (DSL). Nice touch of history about DSLs and their roots in functional languages like Lisp. Nothing definitive about how-to write a DSL, but just shows the pros/cons of various approaches. Definitely, a demonstation of building a DSL and a great reference for me if I need to write a DSL.

The Lush Landscape of Languages -- Rebecca J. Parsons
Boils down to a comparison table with some history about the different programming languages compared by: paradigm (imperative, declarative, OO, functional, etc.), typing (dynamic, static, duck), and implementation.

Polyglot Programming -- Neal Ford
This is a nice beginner article on the various programming languages that can be run on a common platform like .NET and Java. Neal shows a simple task written in Java, then in other JVM languages like JRuby, Jaskell, Scala, and Groovy. My favorite point that he makes is that even if your production code is written in Java, you can still test it in another higher level language.

Object Calisthenics -- Jeff Bay
9 rules that you should try to become a better developer.

1. Use only 1 level of indentation per method - more than 1 level usually means dealing with more than 1 abstraction.
2. Don't use the else keyword - the rule seems weird, but the idea is not to let conditional branching go nuts.
3. Wrap all primitives and strings - try to give meaning to numbers like year, month, day instead of just using a scalar integer.
4. Use only 1 dot per line - this is an ease of readability thing.
5. Don't abbreviate - the naming of things should be concise and meaningful.
6. Keep all entities small - guideline: a class ~50 lines and a package ~10 files.
7. Don't use any classes with more than 2 instance variables - a class should maintain a single state.
8. Use first-class collections - wrapping collections in a class so that behavior for a group of objects in the collection can be defined.
9. Don't use any getters/setters/properties - "Tell, don't ask"

What Is an Iteration Manager Anyway? -- Tiffany Lentz
I've personally never heard of this job title, but it seems to work for ThoughtWorks. An iteration manager is responsible for making the iterations successful and dealing with stakeholders and developers very closely. Managing iterations is very different from managing a project, and those two tasks are sometimes a conflict of interest. A project manager's primary responsibility is to deliver the project on-time and on-budget. But the iteration manager will make sure the developers work at a sustainable pace, producing quality software, and gathering and providing feedback on what can be done by the team.

Project Vital Signs -- Stelios Pantazopoulos
A further explanation on what an iteration manager does by an actual iteration manager at ThoughtWorks. Focused on providing visibility and feedback to project stakeholder by using various information radiators.

Consumer-Driven Contracts: A Service Evolution Pattern -- Ian Robinson
This is my favorite essay on how to build a reusable service. It compare 3 approaches: provider, consumer, and consumer-driven contracts. Provider contracts are how most people build services: the developers generalize the data they have and provide an interface to that data. Consumer-driven is when the provider works with the clients to make sure they expose the bare minimum interface that the consumer needs. The goal is to produce a lean contract with the consumers to the extent that they meet business goals. The key is not to implement exactly what one consumer wants, but instead letting the consumer's business needs drive the development of services.

Domain Annotations -- Erik Doernenburg
Goes over the various advantages of using Annotations (Java) and Attributes (C#). Domain annotations make it easier to separate domain-specific code from infrastructure code.

Refactoring Ant Build Files -- Julian Simpson
A good essay on how to improve your Ant build file. Luckily, I already knew most of these. It did remind me why some target names start with a hypen (-), because those tasks can't be called from the command-line.

Single-Click Software Release -- Dave Farley
The idea is to extend the automation idea in continuous integration as close to continuous deployment as possible. The ultimate goal would be able to deploy to production with an automated script. Removing human steps as much as possible to reduce human error.

Agile vs. Waterfall Testing for Enterprise Web Apps -- Kristen Vingrys
Basically, defines how testing works in an Agile project by contrasting with a waterfall way of testing.

Pragmatic Performance Testing -- James Bull
Written by a QA person, he discusses performance expectations, how-to deal with performance during development, and a lot of other questions surrounding performance in software projects.

Behind Closed Doors: Secrets of Great Management (Book Review)

I just read "Behind Closed Doors: Secrets to Great Management" in 1 day, cover-to-cover (~160 pages). Great read, reminded me of a contemporary, dialogue version of "Peopleware". Other notable differences: focused more on people dynamics rather than workplace things, like "furniture police".

So, now to the book:

The book is written in two distinct parts: the first half (pp. 1 - 123) a narrated dialogue of a newly hired manager's (Sam Morgan) experiences with subordinate and superior managers, and the second half was a references/reminder section on all the tips presented by the book. Seven (7) weeks of experiences by Sam Morgan were explored while trying to acclimate to his new team and address existing team issues, all the while pleasing his new boss despite the release schedule being moved from 5-months to 3-months.

"Great management is about leading and developing people and managing tasks." -- from "Behind Closed Doors"

The book goes on to elaborate on the importance of the management focusing on what brings value to the company, and that this should be the focus of all levels of management. In my relatively short career, I've seen managers diligently try all the techniques in this book, but often forgetting the "value to the company" part.

Why do managers seem to lose sight of "value to the company"?

Management is overhead. Granted, it's a necessary overhead once a team grows beyond 10+, or grows into multiple teams. But in some companies, the management overhead grows so large that it begins to serve purposes other than maximizing company value and productivity of people. Once management grows beyond the bare minimum required, then wasteful and potentially destructive politics and protectionism occurs.

In software development companies, today's managers were yesterday's technical leaders. You can NOT be a manager and technical leader at the same time. They are completely different roles, but they do have overlap so people think they can be done the same person. The distinction is hard to make, because both managers and technical leads manage their subordinates.

Managers should focus primarily on the company goals and strategy, and then work on potential tactical solutions with their technical leads. In our software industry, we already know how to find technical leaders for our teams. They can successfully lead a team of software developers. The hardest and most useful thing to do is get the communication and relationship right between the managers and technical leaders. Managers and technical leaders should have a very overlapping role when it comes time to plan, prioritize, and schedule work. Managers have their charge of "providing value to the company using IT resources", while technical leads have their charge of "providing advice, assisting planning, implementing, and supporting software solutions".