Subscribe
Posted on January 27th, 2009
What does discipline mean to you? Looking at the definition from Merriam-Webster Dictionary, it could mean:
- punishment
- (obsolete) instruction
- a field of study
- training that corrects, molds, or perfects the mental faculties or moral character
-
- control gained by enforcing obedience or order
- orderly or prescribed conduct or pattern of behavior
- self-control
- a rule or system of rules governing conduct or activity
In the software community, we seem to equate discipline to specific techniques. Therefore, in talking about disciplines of a software developer, it isn’t uncommon to hear things like Test-Driven Development, Pair Programming, etc. But to me, those are all practices of specific camps. My definition of discipline is more in line with this:
Discipline is what kicks in when motivation takes a holiday. It keeps you going to class, keeps you pushing yourself even when you’ve hit a never-ending plateau and you just want to go home and curl up in bed. Discipline will keep you training until you fall in love with your art all over again…and the cycle starts again.
In other words, to me discipline is a cross-cutting concern. You may do RUP, I may do XP, Sara may do Scrum, someone else may practice Crystal Clear. Or, to equate it back again to martial arts – I may do Judo, you may do Jujitsu, Sara may do Kung-Fu, and someone else may do Karate. But there are concrete disciplines that the students from all the camps have: Respect, Honor, Practice, Mentoring. These things make up some of the core disciplines that defines a martial arts student.
In a similar vein, there are core items that students from all software camps can articulate. Certainly Respect is one. Mentoring is another. Things that are not just concepts held across camps, but concepts which can be articulated. For example, if I kick you in the face at the beginning of a match as we’re bowing to one another, I’ve violated the discipline of Respect, and rightfully should be tossed out of martial arts. I may still practice the same things, I may still be able to perform the same moves, but I’ve forfeited my right to be called a student of the art. I’m a thug.
Looking at an initial shot at a Software Craftsmanship Charter some of those things are on there – Respect, Responsibility, Mentorship. I’m wanting more. I’m wanting things that we can take to students – whether they be high school, college age, or just from the school of life – and say, “Regardless of the specific techniques practiced at your company, these are steps you can take to becoming a true craftsman”. We’ll likely find some overlap with Team Building, accountability and others.
But the one thing that should hold true is that, no matter the camp, no matter the practice, we can hold it to the litmus test of the core disciplines and know where it stands. Which also means we can hold us to the same test, the same disciplines. And that might be scary for some. But if we want to truly turn this industry around, we have to start defining foundations that are unshakable.
What are your disciplines?
Posted on January 25th, 2009
At the recent TDD Firestarter event here in Tampa, a second issue came up in the reviews – namely why we chose to use NUnit over MSTest (given that it was held in an Microsoft office). Several reasons came up – cost (MSTest requires Visual Studio Pro), integration (MSTest requires Visual Studio to be installed on your build server to run tests as part of a CI build), and extensibility (have to wait a full dev cycle to get interesting things added in).
I will give MSTest credit for opening the eyes of those at “Microsoft-Only” shops (and yes, they do exist) to unit testing at the developer level. However, it’s time for a change – and Christopher Bennage raised an interesting idea on Twitter tonight. Instead of shipping MSTest, why not just integrate an external framework like NUnit, MbUnit or xUnit.NET ala the JQuery integration?
It gives the community the integration they long for, while allowing the framework to remain agile and open to modifications without having to go through a whole dev cycle. You’d have to figure out TFS Integration, and things like the DBPro Unit Tests. But it would be a great next step for truly helping introduce quality to the dev tool space within Visual Studio.
Posted on January 22nd, 2009
At the recent TDD Firestarter here in Tampa, a question came again that was a repeat of one from my TDD/MVC talk at Agile Tampa a couple of months back. Then, at the after-party of the Firestarter event, Joe Healy talked about needing a 10-step program for introducing TDD.
I gave some thought to this, and even outlined steps. But my mind kept going back to that question. The very strange question. The one that goes:
“How to I convince my management to let me get started in TDD?”
To answer, I want to take you back to earlier in 2008. I was sitting in a large hall being entertained by an uncle. Well, not my uncle, but Uncle Bob Martin. He was giving a talk called Quintessence: The fifth element for the Agile Manifesto. In it, he uttered the now infamous fifth addition to the Agile Manifesto:
Craftsmanship over Crap
Much was said about this statement, about how it didn’t fit in to the other items (since we never really value crap), and if there were better ways of phrasing it. Well, here ya go.
There isn’t.
We have a problem in the software world. A problem that those 3 words uttered by Uncle Bob, filled with passion, almost a plea, drives home so clearly for me. You want responsibility? You want to change things? You want better tools, better processes, better software, more time at home, more money, etc, etc?
Then get off your butt and do it.
I’ve had the opportunity to see real craftsman at work – not in the software industry (although I have), but in ones like woodworking, metalurgy, and others. These people, these craftsman, have no ego. They know what they know, but aren’t afraid to learn new ways. They are equally not afraid of teaching, mentoring, showing examples of how to get better. They are teachers. They are mentors. They understand that to change things, to make things better, to get better, they have to work hard.
So, when they are building a beautiful Oak cabinet, or welding some critical piece of infrastructure, do you really think they go, “Wow, I learned this method that will greatly improve everything I do, will increase the quality, decrease my defects, and allow me to help people understand what it is I’m doing. If only my boss would let me do it.”
Bull Hocky. That’s a cop-out. A pathetic one at that. One that says that even though you know a better, faster, stronger way of doing things you are going to keep it to yourself. Worse, you are going to hide behind an excuse.
You want to know how to improve your software? You want to know how to become a better developer? Look to the craftsman. Get off your butt, get to some code, and start writing tests. Or pairing. Or translating business language to acceptance tests. Find a bug? Write a test that exposes it, and then is green when the bug isn’t present. Set up a local CI server. Make sure your stuff works. Know the SOLID principles. Know what the PoEAA book is. Look up things like Domain-Driven Design, Test-Driven Development, Behavior-Driven Development, Acceptance Testing, FitNesse, Ruby, Python, RSpec, Cucumber, NUnit, MbUnit, xUnit.NET, JUnit, JMock, JBehave, ScrewUnit, Spec#. Figure out why people always laugh about refactoring in Visual Studio and point to Eclipse. Figure out why the Visual Studio people laugh at the Eclipse people. Try J2ME. Try Windows Mobile. Try iPhone development. Learn Haskell. Learn F# (or just talk to Matt ;)). Learn Smalltalk. Read Death March. Read Slack. Read The Mythical Man Month. Read Clean Code. Find Computer Science books and read those too. Go to local meetings. Go to national conferences. Speak at Code Camps and user groups. Learn, and teach, and do, and learn, and teach, and do.
But don’t sit there and wonder how you’ll get your manager’s approval. If we want to change this industry, we aren’t going to do it with excuses. We’re going to do it by getting out there and being a part of it.
So, to summarize, how do you get your manager’s approval to do TDD? You don’t. And you do it anyway. Change your organization, or change your organization. But don’t just sit there. If you don’t run, you rust.
Posted on January 20th, 2009
This past Saturday, I got the great pleasure of hanging out at the TDD Firestarter event here in Tampa. It was great fun, and I even got to wow the crowd with demos on FitNesse, Cucumber and DBPro.
I also got some decent pictures of the crowd and activities. You can see what I’ve uploaded on my Flickr page.
Posted on January 5th, 2009
As more organizations have worked to implement agile practices, some teams have found wisdom in Lean Principles to guide them along. Some teams have even found ways to get rid of timeboxed iterations altogether and move towards Kanban – a pull based system for getting things done.
If you’ve heard about Lean and Kanaban, or are interested in hearing more about it, and want to get away from whatever winter weather is your way, do we have a treat for you. On February 18th – 20th in Miami, FL, the first Lean Kanban Conference will be held with some great speakers like David Laribee, David J. Anderson, Corey Ladas (of Scrumban fame, and many others. Registration is limited to 125 people, so get over to the Agile Florida post, download the flyer, and then head over to the Conference site and get yourself registered!
Posted on January 1st, 2009
When my wife got an Touch several months back, the first thing I wanted to do was build some applications for it. Who wouldn’t want to play with a device that has accelerometers, position sensors and multi-touch gestures? But being new to the Mac world, I needed something to help guide me along. Beginning iPhone Development aims to be that guide. But does it live up to the challenge of teaching a newbie Mac and iPhone developer?
The first thing you’ll need to do is head over to the Apple Developers Site and register for an account. You can then download the iPhone API. Note that while the API download and simulator are free – deploying to a real iPhone or Touch is not, even if it is your own. To do that you have to apply to the iPhone Developer Program which is $99. For the book, you’ll be fine with just the simulator with the exception of any accelerometer application, since the simulator doesn’t have that feature.
With that out of the way, I was quite impressed with the book. Although I’ve done quite a bit of development in the past, I haven’t worked with Objective-C before, and was a little concerned if I would be in over my head. If you are in that position, don’t fear – the authors do a great job of walking you through, and you’ll find yourself working with it in no time.
The first chapters introduce you to the basics of the iPhone and development, starting with the canonical “Hello, World” application. The book walks you through how to get and install Xcode and the iPhone API. It then introduces you to Interface Builder, the partner-in-crime to Xcode. Even in the first chapter, the authors show their attention to detail, explaining common issues you might run into (like trying to Build and Run while your iPhone or Touch is plugged in to your Mac).
Chapter 3 introduces the Model-View-Controller paradigm, a pattern that is probably one of the most misunderstood patterns in UI development. They give you enough information to be familiar with the terms you’ll be using, and they very much mean it when they tell you not to worry if you aren’t understanding something – they always loop back around to make sure you understand it.
Chapter 4 was a long chapter for me, but introduces some important concepts around user interaction and controls. By the end, you have an interface which has a variety of controls which interact with each other. As with the other chapters, the authors introduce tips and tricks to make things easier (for example, Option->Cmd->Up Arrow to switch from the header to implementation file in Xcode).
Chapter 5 covers autorotation and basic animations, including linking in the Core Graphics Framework. I especially like how the authors gave three different ways of making your app auto-rotation aware, describing the benefits and drawbacks of each. Chapter 6 follows this up by introducing multi-view interfaces, something very necessary as you get into more complex iPhone development.
Chapters 7-9 describe various methods to presenting information to users, including toolbars, table views, hierarchical navigation and hierarchical lists. However, it isn’t all drag-n-drop, the authors get into some good (and sometimes deep) conversations about what you are doing. For example, in Chapter 8, they talk about issues with NSDictionary and how to create deep mutable copies.
Chapters 10-13 are the last of the “fundamentals” – application settings, basic data management, custom drawing using Quartz and Open GL, and taking inputs (including gestures and multi-touch). As someone who spends most of his time as far away from graphics libraries as possible, I was quite impressed with the basics that were introduced and what someone like me could get up and running.
Finally we get into the fun. Chapter 14 introduces Core Location, allowing to figure out where in the world you are. The book goes through a discussion about the various ways to get location information, and drawbacks of each. (Helpful tip: no matter which method, if you are polling every second, you’ll drain the battery pretty quickly). For the simulator-only users, this is when things start to become tricky. Chapter 14 does work, though you aren’t prompted for access to Core Location.
Chapter 15, however, is useless without an actual phone, even though it’s perhaps the most fun. In this chapter, the book goes through the accelerometer and all the interesting things you can do with it. There’s even a small discussion on the physics (but just enough!). Both apps you create (Shake and Break and the Marble game) are quite fun for someone just starting out with all of this. It’s a shame Apple couldn’t figure out a way yet to include the accelerometer in the simulator.
Chapter 16 covers using the iPhone camera and Photo Library. It’s short, but it shows the power of the simple interfaces Apple provides. In just 9 pages you’ll be capturing images right from the iPhone.
The final two chapters I thought were quite fitting – Localization and Follow-Ups. In the localization chapter, the book covers extracting strings out to resource files and using locale to read them in. Having a day job which ships our software in 12 different languages, I know first-hand how difficult localization can be to get right, so I was glad to see this chapter. The final chapter is just a wrap-up of resources you can reach out to for help and information.
All in all I was very surprised and pleased with the book. I’ve had the fortune of reading many technical books, and few do a great job of walking someone through the basics without making them feel like a dolt. It felt like every time I was stuck or unsure there was a tip, hint or paragraph which explained what was going on.
The main drawback to me is the fee to deploy apps to your own phone. This wasn’t something I ran into doing either J2ME or Windows Mobile apps in the past, and it is a shame that to even work on your own phone you have to pay a fee. However, since the fee does give you the ability to submit apps to the App Store, then I guess it’s a consolation. I’d rather Apple lock deployments to one iPhone (or Touch) for the truly casual people who just want to do interesting things on their own phone.
In summary, I give this book five $1000 Rubys for making a clean, concise, easy-to-read and follow introduction to iPhone development. Great job guys!