All That I Know (About Technology)

One of my favorite blogs on software development is Jeff Atwood’s Coding Horrors. Jeff is a programmer turned blogger that has a unique (and real) perspective on the psyche of developers. His blog posts are based on a topic that he’s researching for work or fun, which is something that I also do regularly.

In a recent search, I came across a blog posts from 2006 on “modern software development” (source) where Jeff he explains that development really hasn’t changed much in the past ten years. Based on my experience of working with developers both on client and agency side, I think that he’s spot on. Looking at his list, I came up with only a single addition (which appears in red/bold) for traits of modern developers:

• Store code in a source control repository. The beauty of using source control solutions, such as SVN/subversion, Git, or Visual Source Safe (VSS), is that a team of developers can develop code without overwriting each the changes made by each other.
• Deploy code using scripts. With a script, developers can automate the launch of a website, this ensuring that nothing is missed in the process.
• Develop using TDD or Test-driven development. Instead of writing code first, developers focus on writing tests for their code. This provides a solution to limit the number of bugs as a unit test can also serve as a low-level regression test as new code is introduced.
• Reuses code when possible. Modern developers know that they don’t need to re-invent the wheel. Instead of rewriting code, they tend to reuse code that’s already working. This translates to saving development time, plus it allows developers to focus their energy on learning something new.
• Apply the Model–View–Controller (MVC) architectural pattern. Since code is logically separated into 3 tiers (data layer, presentation layer, and business layer which connects the other two), developers can more easily maintain their code.

The good news is that the barrier to become a modern developer is low. Old school developers only need to adopt the MVC pattern to be new again.

NOTE: Stonehenge photo was provided by Danny Sullivan.

I just finished up the book Ignore Everybody: and 39 Other Keys to Creativity by Hugh MacLeod. The book is actually a collection of entries from Hugh’s blog where he talks about his hobby of drawing cartoons on the back of business cards. It was a short read — but it was packed with great life lessons, especially if you’re a product manager. Like a product manager, Hugh had to produce and promote his product (art on business cards) while facing plenty of criticism. This book reminds us that there are no such things as shortcut — the road to success is a long one. The three big lessons that struck a chord with me included:

Stay Focused. Once you find a direction, you have to stick with it. People may try to sway you with their opinion but you can’t let that get in your way of success.

Work Hard. You have to keep plugging away at your dream even if there’s no immediate reward. Theodore Roosevelt actually said the same thing: “Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty… I have never in my life envied a human being who led an easy life. I have envied a great many people who led diffcult lives and led them well.”

Keep Practicing. If you want to get better at your craft, you have to do it again and again. There are no shortcuts. (NOTE: Jeff Atwood seems to repeat this message in his blog on development; see here).

Hope that you get to enjoy this book as much as I did.

The Iron Triangle allows for only two factors in determining the success of a web project. But the impact of the client’s perspective on the triangle seems to reduce the two factors into a single option.

Early on in my development career, I leaned how the Iron Triangle impacts projects. The iron triangle (aka the Project Triangle) is a software development concept that says that the quality of a project is determined by three factors:

• Timeline. How long you have to complete a project?
• Budget. How much is the client is willing to pay for the work?
• Features. What functionality can be built?

The point of the Iron Triangle is that you can pick or constrain only two of these three factors. So if the project timeline and features are constrained, then the budget must grow. If all three factors have to be met, then the quality of the web project will be sacrificed. While this concept seems to give developers some breathing room, the Iron Triangle seems to be further constrained when the client’s perspective is taken into account. Let me explain.

A client typically approaches web projects with two constraining factors. When a client requests a solution, they normally constrain the project by asking that the solution be delivered by a certain deadline. The deadline is normally set because the client needs to meet a pre-determined objective, such as seasonal promotion, customer acquisition campaign, etc. Additionally, when a client requests a solution, they further constrain the project with their budget. Since money doesn’t grow on trees, the client will dictate how much they can spend for development on a project to be completed.

So when the client’s constraints on a project are taken into account, the Iron Triangle is actually reduced to a single option: project features. This means that developers have to look at how many features they can implement for the time and money that they are given. The good news is that the feature list can be functionaly robust or weak. That means that there’s some play in what the client will or will not get for the time and money that they’re dedicating to the project.