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

Cairngorm is so ridiculous

Cairngorm is an MVC open source framework currently supported by Adobe. This framework is basically a dead project. Last release: 2.2.1 on May 30th, 2007, and only pre-talk about the need and features of an unlikely v3.0. I've used Cairngorm before and immediately didn't like it, but I decided to take an in-depth look at it because it seems development teams are still using it, and I might need to know it.

What's its benefit?

Well, Cairngorm restricts how a developer can interact with data, business layer, and view objects. And the restriction isn't even from the framework: it's just the honor system. But this agreed upon way to get services and execute a sequence of operations ("commands") would help get a mid-to-large inexperienced development team more organized. This pattern would help limit developers exploring new and different ways of doing the same thing.

Drawbacks?

Many. Whoever wrote this really wanted to use as many patterns as possible. One that really bothered me was the use of marker interfaces, namely IModelLocator and IValueObject, to add metadata to classes, yet nothing in the framework uses that metadata! This framework can serve as a crutch to those that don't want to dive into what Flex allows you to do, and this can lead to a popular anti-pattern "the golden hammer": when you only know how to use a hammer everything looks like a nail.

Flex is an event-driven programming environment with tremendous possibilities, and I'm not a fan of Cairngorm trying to limit it so people don't end up writing unmaintainable code.

As I expected, I wasn't the first to have this reaction to Cairngorm. So here is a great post I found after writing my post.

http://blog.iconara.net/2008/04/13/architectural-atrocities-part-x-cairngorms-model-locator-pattern/

Code Mash 2009: Best value conference

I've been to a few conferences in my career: JavaOne, Dr. Dobbs, No Fluff Just Stuff, and some others. And it seems like pretty much the same guys are there presenting the same stuff. I'm thankful that smaller conferences are starting up, and targeting a regional audience. When I go to a conference, I want to interact with real practitioners of these technologies, and not just walking/talking commercials. I don't think these presenters intend to be walking commercials, but it just happens when you're on the speaking circuit for so long.

Most conferences are for companies.

Conferences like JavaOne, SpringSource, RailsConf, RubyConf, Dr. Dobbs, are a single event in one place per year. This means, that unless you live in the same city as a particular conference, you'll need to travel to get there. Traveling to conferences is generally expensive (air+hotel+car+time off work); conferences know this, and that's why they choose expensive venues in expensive locations and when you get to the registration fee of >$1K USD it doesn't seem so bad compared to all the other expenses. Usually, these conferences are during the work week. :( These conferences are a way for companies to reward valued developers.

Some conferences try to be better

No Fluff Just Stuff, as its name explicitly claims is all about technology stuff. Unlike other conferences, this conference is on a weekend, and also is held in various cities each year. I'm a big fan of NFJS, but there needs to be more conferences like this.

So along comes Code Mash v2.0.0.9, which is filled with great presenters, and targets regional developers. For the very reasonable early-bird price of $135, you get a 2-day conference on a Thurs/Friday in Sandusky, OH. With a great hotel nightly rate of $88/night at the Kalahari Resort (largest indoor waterpark in the USA), it's a fantastic deal.

Code Mash 2009 is the only software conference that I've EVER paid for from personal funds.

What's Agile trying to tell me?

I've read books on Agile, and I've received Immersion Training from Object Mentor Inc., and some of that training directly from Uncle Bob Martin himself. And I see one core idea behind Agile that exists in all aspects of Agile development, and I thought I'd write about it here.

Most companies/developers/people seem to have a tough time adopting Agile as the way to go. Or some adopt parts of 'Agile' and morph it into a bastardized version of their existing software development process. I won't go into the details of Agile, but instead look at it holistically.

So what is Agile trying to tell me?

It wants everyone to work together to reach the goal. The problem with most projects is they treat software development as a "service". Clients that need some software built for them think "i know what i want. now if i could only find someone to build it for me." Then they express their wants/needs in some way that they provide to the developers.

Ummm ... but then what?

Clients seem to be able to just wipe their hands, and wait for the development machine to produce what they asked for on the other side. And I can understand this. Services work that way: you ask for something, and then the service provides the promised result.

Software development is NOT a service!

It's a constant brainstorming session between a client and the builder. If the client didn't need a solution for a very specific problem, then they'd probably just buy a software product as a solution. But instead, they need someone to tailor a solution to fit their needs. Agile stresses the importance of runnable/demonstrable software over documents and agreements. Documents and words can be misinterpreted, but functional software can be 'seen' by both the client and the builder. At this point, they are in sync. The client can ask for something and the builder can build it. And after each iteration, the builder and the client can both come together toward a common vision of the solution. Similar to tailoring a very expensive suit: you wouldn't just take some measurements and send it off to be altered. You'd want to be there with the tailor, making sure every adjustment was just right for you.

Final Thought: There shouldn't be clients requesting work from builders, but instead the clients requesting to work with builders. This is how I hope to work someday. Working closely with clients so that I can understand what they want and need. So that I can help them understand what they want. So that I can tailor the solutions and products that they need.

Whoohooo, first midnight blog post.