Tuesday, March 31, 2009
Monday, March 30, 2009
Agile isn't easy
I'm sure other people tranistioning to agile have had this thought. Isn't agile supposed to make my job easier? Won't I have more time to golf and relax? And yet, agile seems to be harder, and require more work and effort, than doing things business as usual. Well, guess what? Executing great work at the highest level is hard! It's harder than business as usual. But it pays dividends. You delight your customers, you have a happy, satisfied team doing valuable work.
The moment the team stops doing work against stories its committed to, the magic leaves the room, quickly and dramatically. This is your fault as the product owner or business manager, not the teams. Business inputs will constantly distract you, customers will constantly derail you, personal issues will manifest in your team's lives. The world will never cease in its efforts to derail, and that's why you have the hardest job of all as the product owner. You're the glue holding the whole thing together, keeping the world at bay.
It actually reminds me a lot of skeet shooting. Shotguns are weird weapons, and skeet shooting is quite the challenge: you're trying to hit a moving target with an explosive burst of shot. You're not sitting there at the range, lying prone, taking as much time as you need to put the bead on the bullseye. You've got at most 2-3 seconds where the clay will be close enough to the target area where your shot will hit it with any force.
The magic of the shotgun is that you don't aim down a site. You line up your vision to the sites - you put your entire upper body and vision in alignment so that you can follow the target with your eye. You no longer aim. You see the target line up, you squeeze the trigger, and pow! it explodes.
This reminds me a lot of setting the goals for a sprint. It's all mental. You have to line everything up to hit the target before shouting "pull!" and if you don't, you're guaranteed not to hit this elusive target. Go down to your local clay shooting range and try it out, you'll find it weirdly identical to leading a software team. Take your whole team as a team-building excercise. There's something interesting that happens when you fire deadly weapons together safely.
The moment the team stops doing work against stories its committed to, the magic leaves the room, quickly and dramatically. This is your fault as the product owner or business manager, not the teams. Business inputs will constantly distract you, customers will constantly derail you, personal issues will manifest in your team's lives. The world will never cease in its efforts to derail, and that's why you have the hardest job of all as the product owner. You're the glue holding the whole thing together, keeping the world at bay.
It actually reminds me a lot of skeet shooting. Shotguns are weird weapons, and skeet shooting is quite the challenge: you're trying to hit a moving target with an explosive burst of shot. You're not sitting there at the range, lying prone, taking as much time as you need to put the bead on the bullseye. You've got at most 2-3 seconds where the clay will be close enough to the target area where your shot will hit it with any force.
The magic of the shotgun is that you don't aim down a site. You line up your vision to the sites - you put your entire upper body and vision in alignment so that you can follow the target with your eye. You no longer aim. You see the target line up, you squeeze the trigger, and pow! it explodes.
This reminds me a lot of setting the goals for a sprint. It's all mental. You have to line everything up to hit the target before shouting "pull!" and if you don't, you're guaranteed not to hit this elusive target. Go down to your local clay shooting range and try it out, you'll find it weirdly identical to leading a software team. Take your whole team as a team-building excercise. There's something interesting that happens when you fire deadly weapons together safely.
Wednesday, March 25, 2009
Google Guice
don't know how i missed this... http://code.google.com/p/google-guice/. "Put simply, Guice alleviates the need for factories and the use of new in your Java code. Think of Guice's @Inject as the new new. You will still need to write factories in some cases, but your code will not depend directly on them. Your code will be easier to change, unit test and reuse in other contexts. "
Business Process
I have to write an actual full post about good customers and business process - how are you going to go from unloading product on the loading dock to getting it to your customers' front door?
Tuesday, March 24, 2009
High quality developers and language flame war retards
Having now built out my team of developers, I continually refer back to my experience of being interviewed by and performing interviews for Amazon. I've been feeling a lot of frustration at Ruby Kool Aid - and not for the usual reasons at all. The real annoyance for me is just like Republicans cloaking themselves with the flag while they systematically looted the country for 25 years and sent it to hell, Ruby foamers think they know how to write good software because they can bang out a RoR site quickly. The reality is that the Ruby scene has become densely populated with a large number of charlatans who are just like the sucky php and perl hackers from days of yore: array bashers and hash smashers who put 2000 lines of junk in a controller and call that agile high quality scalable code.
I've had 2 major problems with software in the past: unmaintainable code and performance. Sooner or later, when enough people are pounding your website at the same time, you'll have performance problems, as any decisions you made that are suspect will get grossly magnified and you'll have to do some careful analysis and get it fixed. I don't care if you write in Java or C# or RoR, this will be true. But if you wrote good maintainable code that follows principals, it again doesn't matter what language you wrote it in; you can fix it. And the reality is, regardless of technology, most software gets thrown out at this stage due to the steaming shit pile condition it is usually in by the time performance becomes an issue. Just like any other solution, RoR doesn't and can't force the desperate hackers to write good code; but for those that know what they're doing, they can write well-designed software in any language or environment (well maybe except php hahahaha just kidding).
This was the Amazon way of finding talent. You looked for people who could solve problems quickly, efficiently; who could handle the stress of a day of hard problems; who liked to bite their teeth into a challenge; etc. They were language agnostic in the interview. You could write any kind of pseudocode you wanted. It was all about well-formed thought under pressure. This of course was because the existing code base was so bad that you had better be able to fix super gnarly problems after getting paged at 3am but that's another story.
I swear I will never become an evangelist for any type of technology. I will always promote developers delivering high business value software that achieves the objectives. I think if you are still in the software game in your 30's and beyond, you get bitter -- I mean ok everyone who makes it out of their 20's in one piece is going to be a little bitter -- and you kind of keep on fighting last year's war. I think a lot of java veterans who are now Ruby nuts do so because of spending years and years working on million-line J2EE projects from hell that were designed by management and not developers. Again, Ruby isn't the solution: the solution is letting engineers design software that delivers business value.
The true war I fight and the true problem with the profession is the never-ending gap between business stakeholders and implementation teams. Both sides need to develop a shared understanding of business value and then go implement it. Now in Rails' favor, you can get a lot more done quickly to get something up and running in Rails, absolutely no doubt about it. The other day I was messing around with Apache Axis2 as I fantasized about replacing ActiveRecord with a bunch of Web service calls and a Java back-end, and I was immediately reminded of all the awesome things you don't have to deal with in Rails. There's quite a bit of fucking about just to get a java web service up and running. I think the challenge of desiging a well-formed API is just as hard in either language, but Rails lets you sketch it out a lot faster. Anyway I don't care how it gets done, in any environment, if you know what you're doing, you'll get 80% of the way there in a few days and then spend 3 weeks getting the last bits right.
I've had 2 major problems with software in the past: unmaintainable code and performance. Sooner or later, when enough people are pounding your website at the same time, you'll have performance problems, as any decisions you made that are suspect will get grossly magnified and you'll have to do some careful analysis and get it fixed. I don't care if you write in Java or C# or RoR, this will be true. But if you wrote good maintainable code that follows principals, it again doesn't matter what language you wrote it in; you can fix it. And the reality is, regardless of technology, most software gets thrown out at this stage due to the steaming shit pile condition it is usually in by the time performance becomes an issue. Just like any other solution, RoR doesn't and can't force the desperate hackers to write good code; but for those that know what they're doing, they can write well-designed software in any language or environment (well maybe except php hahahaha just kidding).
This was the Amazon way of finding talent. You looked for people who could solve problems quickly, efficiently; who could handle the stress of a day of hard problems; who liked to bite their teeth into a challenge; etc. They were language agnostic in the interview. You could write any kind of pseudocode you wanted. It was all about well-formed thought under pressure. This of course was because the existing code base was so bad that you had better be able to fix super gnarly problems after getting paged at 3am but that's another story.
I swear I will never become an evangelist for any type of technology. I will always promote developers delivering high business value software that achieves the objectives. I think if you are still in the software game in your 30's and beyond, you get bitter -- I mean ok everyone who makes it out of their 20's in one piece is going to be a little bitter -- and you kind of keep on fighting last year's war. I think a lot of java veterans who are now Ruby nuts do so because of spending years and years working on million-line J2EE projects from hell that were designed by management and not developers. Again, Ruby isn't the solution: the solution is letting engineers design software that delivers business value.
The true war I fight and the true problem with the profession is the never-ending gap between business stakeholders and implementation teams. Both sides need to develop a shared understanding of business value and then go implement it. Now in Rails' favor, you can get a lot more done quickly to get something up and running in Rails, absolutely no doubt about it. The other day I was messing around with Apache Axis2 as I fantasized about replacing ActiveRecord with a bunch of Web service calls and a Java back-end, and I was immediately reminded of all the awesome things you don't have to deal with in Rails. There's quite a bit of fucking about just to get a java web service up and running. I think the challenge of desiging a well-formed API is just as hard in either language, but Rails lets you sketch it out a lot faster. Anyway I don't care how it gets done, in any environment, if you know what you're doing, you'll get 80% of the way there in a few days and then spend 3 weeks getting the last bits right.
Not the only one who thinks constraints are required
An older post by Obie Fernandez speaks to the constraint thread I find running through many disciplines. I've now spent almost 8 months trying to bring agile to a traditional design agency and we've had some amazing success and terrible failures. I went back and read through all my blog entries I created at the start of this journey and I never explained what my thoughts and perspectives are on constraints.
When solving a problem in a problem space with almost unlimited possible solutions, such as architecture, graphic design, or software engineering, the use of an over-arching design principal is absolutely required for success. Really good solutions often rendre the underlying principal invisible. The visitor to the solution site (words, websites, code) may not be able to immediately artiuclate what the principal or principals were, but they can immediately tell a well-ordered paradigm. The Kool-Aid crowd of the RoR scene has embraced a very strong design principal in Rails. What are some other examples of this principal at work?
Graphic designers have to tell a story when creating their portfolio. There has to be an arc to the story they tell. It's often useful to think, ok, this portofolio is going to evolve along the color wheel. The start of the book will be red, then green, then blue. I will tell a story using color. The solution is transparent, yet the visitor feels a smooth sense of flow to the book without knowing why. It doesn't matter whether they identify the arc or not, its existence and the book's adhearance to the rule makes it coherant.
Usability is the study of creating a coherant language in your software site. The use of personas and stories with a "so that" clause are great examples of creating a well-defined guiding principal that leads to a condition of self-contained coherance. It is very much a semoitic practice. Well designed software contains a very easy to grasp completely consistent internal logic. It may be for grandma instead of Skippy Jr., but it doesn't matter; when the logic is consistent (due of course to rigid adhearance to a simple constraint), the user is able to explore and map out the semoitic rules of the system. The surface of the software is discoverable and the way through the rabbit hole quickly becomes well-known.
OOAD uses this same technique. A well designed object has multiple constraints: closed for modification but open for extension; clearly defined responsibility; encapsulation; loose coupling; etc. When you read code that follows these prinicipals, you always already know what it does when you read it. The more you read the good code out there, you start to absorb the zeitgeist of patterns subliminally, and you start to try to factor your own code to follow these well known best practices.
Biggest take away from trying to do things right: It takes constant, ceaseless, undying devotion. The difference between doing right and doing wrong is not the amount of work or the intensity factor. It's just that you get a lot more high quality work done in less time. Desiging good OO code is really hard and coders under pressure will always revert to desperate perl hacking with arrays and hashes. Doing a stand up every dayis hard because something more "urgent" (but less important) will always come up. Tracking velocity is brutal because every day it tells you that you and/or your management (or client) is full of shit and you're not going to get it all done on time (probably because most of what you're doing is not valuable anyway and you haven't thrown out the junk with enough constraints - you were driving to get the dollar rather than being driven by a well defined ROI MMF business reality).
Biggest Failures
Biggest Successes
Ok this post is like a mega brain fart that has books worth of ideas in it, but i just needed to blat some of this out and get on paper so to speak. I need to really develop this idea of design constraints as a critical component for success. My unique experiences in both the design and software fields, combined with my philosophy background, gives me an interesting perspective (or the ability to endlessly romance the sound of my own keyboard clacking, you decide).
When solving a problem in a problem space with almost unlimited possible solutions, such as architecture, graphic design, or software engineering, the use of an over-arching design principal is absolutely required for success. Really good solutions often rendre the underlying principal invisible. The visitor to the solution site (words, websites, code) may not be able to immediately artiuclate what the principal or principals were, but they can immediately tell a well-ordered paradigm. The Kool-Aid crowd of the RoR scene has embraced a very strong design principal in Rails. What are some other examples of this principal at work?
Graphic designers have to tell a story when creating their portfolio. There has to be an arc to the story they tell. It's often useful to think, ok, this portofolio is going to evolve along the color wheel. The start of the book will be red, then green, then blue. I will tell a story using color. The solution is transparent, yet the visitor feels a smooth sense of flow to the book without knowing why. It doesn't matter whether they identify the arc or not, its existence and the book's adhearance to the rule makes it coherant.
Usability is the study of creating a coherant language in your software site. The use of personas and stories with a "so that" clause are great examples of creating a well-defined guiding principal that leads to a condition of self-contained coherance. It is very much a semoitic practice. Well designed software contains a very easy to grasp completely consistent internal logic. It may be for grandma instead of Skippy Jr., but it doesn't matter; when the logic is consistent (due of course to rigid adhearance to a simple constraint), the user is able to explore and map out the semoitic rules of the system. The surface of the software is discoverable and the way through the rabbit hole quickly becomes well-known.
OOAD uses this same technique. A well designed object has multiple constraints: closed for modification but open for extension; clearly defined responsibility; encapsulation; loose coupling; etc. When you read code that follows these prinicipals, you always already know what it does when you read it. The more you read the good code out there, you start to absorb the zeitgeist of patterns subliminally, and you start to try to factor your own code to follow these well known best practices.
Biggest take away from trying to do things right: It takes constant, ceaseless, undying devotion. The difference between doing right and doing wrong is not the amount of work or the intensity factor. It's just that you get a lot more high quality work done in less time. Desiging good OO code is really hard and coders under pressure will always revert to desperate perl hacking with arrays and hashes. Doing a stand up every dayis hard because something more "urgent" (but less important) will always come up. Tracking velocity is brutal because every day it tells you that you and/or your management (or client) is full of shit and you're not going to get it all done on time (probably because most of what you're doing is not valuable anyway and you haven't thrown out the junk with enough constraints - you were driving to get the dollar rather than being driven by a well defined ROI MMF business reality).
Biggest Failures
- No code review, whether by pairing or old school diffing code check-ins
- Letting ruby kool aid drinkers baffle me with bullshit when i should have seen the desperate perl hacker array and hash smash from miles away (badly named classes with no clearly defined responsibilities, more spaghetti than the tower of pisa, etc).
Biggest Successes
- Creating a true build and deploy cycle so that bad code doesn't escape into the wild
- Pivotal Tracker - it is a relentless pain to constantly drive a whole team, from business leader stakeholders down to developers to all communicate in terms of business value, but the moment you let the devs go off into implementation details or the business owners look for short cuts and quick cash, you will lose your guiding principals, all benefit and value of simple constraints and SDD goes out the window. You can't ever stray from the noble truths.
Ok this post is like a mega brain fart that has books worth of ideas in it, but i just needed to blat some of this out and get on paper so to speak. I need to really develop this idea of design constraints as a critical component for success. My unique experiences in both the design and software fields, combined with my philosophy background, gives me an interesting perspective (or the ability to endlessly romance the sound of my own keyboard clacking, you decide).
Subscribe to:
Posts (Atom)