Allright!
I’ve had this dream, for like ages, to become a published book author. Now I’ve done it. iOS 6 Recipes is out. (Actually, it’s been out since late november but I’ve been so exhausted that I haven’t been able to muster the energy to blog about it.)
iOS 6 Recipes is based on another book, iOS 5 Recipes, by Colin Francis and Shawn Grimes. My job was to upgrade that book with the new features of iOS 6, but as it turned out I had to rewrite most of the original content, keeping only the general structure and most of the old topics. I’m very proud of the result and although there are many ways in which it could still be improved, I believe I’ve accomplished the goal of producing a better book, valuable to its readers.
But I couldn’t have pulled this off if it wasn’t for the fantastic team at Apress, especially Anamika Panchoo (Coordinating Editor), Anselm Bradford (Technical Rewiever), Douglas Pundick (Developmental Editor) and Linda Seifert (Copy Editor).
If you’ve read iOS 6 Recipes and want to share your thoughts, or ask me questions, feel free to contact me, either through the comments here or by emailing me (you’ll find my email address in the book).
Cheers!
I’m reading Growing Object-Oriented Software, Guided by Tests
, by Steve Freeman and Nat Pryce. I was happy to find that the authors share a similar view on constructed generic types as I do.
Our rule of thumb is that we try to limit passing around types with generics […]. Particularly when applied to collections, we view it as a form of duplication. It’s a hint that there’s a domain concept that should be extracted into a type.
A less blunt way of saying what I tried to say in my own post.
If you’re interested in the book I can strongly recommend it. Although I’m only half-way through it I can already tell it’s the best TDD book I have read so far. I’ll have a brief review up in a coming post.
Cheers!
I’m reading Jim Highsmith’s book Agile Project Management
. It’s a good book, as the frequent use of my marker pen shows, except for maybe this one sentence:
“APM reliably delivers innovative results to customers within cost and schedule constraints.”
Let me take that sentence out of its context and make a point I believe needs to be stressed. Software development methodologies (Agile Project Management in this case) delivers nothing! People, on the other hand, do.
Some years ago I developed a special interest in software development methodologies. Since then I’ve spent much time reading literature on Scrum, eXtreme Programming, etc, aiming to optimize the processes we use in our projects. During that time I’ve learned a lot, but also come to realize that I’ve been focusing too much on the wrong things.
In the past I thought the problems we were experiencing were problems with the methodology, an easy conclusion to draw from the propaganda-like information out there. However, I’ve found that the methodology matters little in comparison to the quality of my project team. Today I focus more on the team, the product, and the customer, and less on the latest within agile.
Thus, my formula for a successful project is this:
- Spend less energy on the methodology; i.e. pick a simple one and adapt it when (and only when) needed, or stick to the one you’re currently using
- Do more to get the right people
- Make sure they are motivated and connected
- If you think you’ll fail, do it fast
Summary
If we focus too much on the methodology, and give it too much importance, we risk loosing sight on the real goal, namely producing the right system. And for that you need the right people.
Cheers!
I’m back from my summer vacation. I try to take a long holiday every year and stay away from computers, be with my family, visit interesting places and, of course, read books. Summer is the time of year when I take my reading habits away from the toilet out to the hammock. Time is still scarce but this year I managed to finish five books, mostly in a horizontal position.
As you may know I keep personal logs for almost everything, including notes on the books I’ve read. Now I decided to take that habit and make it public, something I’ve been meaning to do for a very long time. For that reason I’ve set up a new sub domain, reviews.hans-eric.com, where I’ll publish such notes. It won’t be fully fledged reviews, but short posts that primarily reflects how I found the book (or the movie, or whatever.)
Here are four of the books I read during my holiday:
If you’re interested in following what books I read (and what movies I watch,) subscribe to my reviews feed.
Cheers!
I’m an impatient person, of the kind that are comfortable with making quick decisions on loose grounds, but prepared to change when more information gets available. This attitude has served me well, but also put me in trouble when important decisions were made too hastily. That’s why I always use The Rule of Three nowadays.
I first came across this version of The Rule of Three in Johanna Rothman and Esther Derby’s excellent book, Behind Closed Doors
. The idea is to brainstorm solutions to a given problem, and not stop until you have at least three options to choose from. Listing the pros and cons of each solution helps you make a good decision.
With The Rule of Three I’m forced to think broader. I need to widen my view to find possible solutions other than the first that springs to mind. I’ve found that this process makes me explore the original solution better, and the risk of overlooking a good option is greatly reduced. Also, two different solutions can sometimes be combined into a new, even better one.
The Rule of Three can be applied in many ways, within a group or by yourself. It’s a cheap way to build better foundations for your decisions. That’s why I embrace The Rule of Three.
Previous posts in the Tools of The Effective Developer series:
- Tools of The Effective Developer: Personal Logs
- Tools of The Effective Developer: Personal Planning
- Tools of The Effective Developer: Programming By Intention
- Tools of The Effective Developer: Customer View
- Tools of The Effective Developer: Fail Fast!
- Tools of The Effective Developer: Make It Work – First!
- Tools of The Effective Developer: Whetstones
I just finished reading The Google Story, by David A. Vise
. I can’t say it’s a great book. Some parts are terribly boring, stuffed with uninteresting facts and examples. But there were chapters that made me long for my next visit to the toilet. Here is the list of things that caught my attention:
- Larry and Sergey built their product first and raised money later. It’s so much easier to sell your idea if you can back it up with a real and functioning implementation.
- The two founders didn’t start with their eyes on the money. In fact, they had no idea how to monetize their search engine in the beginning. Instead they were focusing on providing the best search experience they could. The focus on usefulness is what laid the foundation to their success. People noticed, trust was built.
- A Google employee (a Googler) are free to spend one fifth of his time at work on a private project of his own pick. One day each week, free to spend on anything that interest you. You’re not just free to do it; you are supposed to do it. It’s your job.
To me that sounds just like employee heaven, but the employee is not the only winner. Some of these private projects grow and end up in valuable products for the company. Just look at the wide range of services that Google provides, many of them started out as private projects.
- Google takes care of it’s employees. Free healthy food and day care for my children would make my life so much easier. That’s another win – win deal between you and your company.
If I ever get to build my own start-up, I will use Google as my template.
Cheers!