Strategy is the process of choosing a broad goal, creating measurable objectives, executing a plan, and seeing if your execution is driving towards the objectives. It sounds incredibly easy, yet very few people are capable of actually conducting themselves in this manner in a professional context. You could ask many reasons why, but that wouldn't help you make the change.
Agile development methodologies are all about coming up with short, concise, measurable objectives in the form of a lightweight spec, such as a user story. I don't know if it is beneficial for team members to really get their head around the mechanics of how an effective strategy works. I think one of the outputs of effective strategic execution is predictable results, such as being able to forecast a team's velocity.
I'll tell a little parable that illustrates how even in the simplest of situations, our emotions and other psychological inputs can distract us from executing our strategy. Anyone who knows anyone from New York City and its environs will be amazed to find that New Yorkers talk about trains the way people in other cities talk about traffic. And anyone who lives in the boroughs is required to understand the nuance and intricacies of the train schedules on the weekend.
My fiancee has been spending a lot of time with me in NYC and I've had to explain all of my strategies to her for effective train riding. Check out the system map if you're not familiar. Our apartment is in Ft. Greene right near one of the busiest subway stations, Atlantic-Pacific. From our house you are within 3 blocks of the A, B, C, D, Q, G, M, N, R, 2, 3, 4, and 5 trains! So the question is often, which train should I take? Well, the entrance that is closest to our house takes you right down to the platform where the B/Q can be caught, so we almost always take these two lines.
So that right there is an example of strategy in action: our goal is to wander the least and catch a train in the least amount of time that will get us to our destination in the least amount of time. The N and the Q are probably the 2 best trains that go through the station, but a stupid strategy would be to go downstairs and if the Q isn't there, go get the N - this is because in the time it takes you to walk to the N, you will probably miss the B or the Q. If I am trying to go somewhere that is only serviced by the Broadway line, I will still just wait for the Q (unless of course it is a weekend in which case I will walk over to the D/N platform since those trains, while requiring an extra walk, are more reliable on the weekend).
Now my office is over on 26th between 6th and 7th. The very closest station is in fact the 1 train station at 7th ave and 28th street. But the 2/3 is really slow and I have to transfer from the 2/3 to the 1, so this route is automatically out of the running. The next closest is the F train station at 23rd and 6th, so if I catch the B train, I have a strategy: if I pull into Broadway/Lafayette or West 4th, and the F train is pulling in at the exact same time, such that I can catch the F with no waiting, it is faster to take the F. Otherwise I just stay on the B and take it up to 34th street, the next stop after W. 4th. While this is a longer walk, waiting for the F is longer.
Does this make any sense? I've optimized my journey for the MOST important objective, which is to get to work in the least time possible so that I can sleep later and eat breakfast at home which is healthier than eating a bagel and cream cheese from the deli. The objective of getting to the station that is closest to my office is less important than getting to my office quickly. Doing the extra walk from 34th street also serves a nice-to-have objective of trying to get as much exercise as I can even when I don't go to the gym.
There are myriad choices to get from my house to the office, and all of them will eventually result in my arrival at work; however, I've clearly identified an objective, which is different from a goal since it is measurable, which is to get to work in the least amount of time possible for the least amount of money. There are many decision points along the way, but by limiting the number of branches in the decision-making process, I have arrived at a very consistent formula. If I take the B or the Q, I know I can be at work, door-to-door, in about 40 minutes. Taking the F may reduce this time by a few minutes, but the risk of sitting on the F train platform for 5 minutes (which happens maybe 1 out of 3 times I choose to do so) is not a risk worth taking.
Teams doing work need to limit their choices and come up with a consistent tactic to getting work done quickly by choosing the right goals and objectives. Over and over again, I find the most effective way to trim time off of projects getting done is to force developers to give me code that I can acceptance test on the build host. I generally don't consider any of the sub-stories of value, I only care about stories like, "As the public, I can see this website feature do something." Plumbing may have been required to get there, but the surest way to know if the plumbing, chores, sysadmin crap, and all other work required to get paid - because that is the mother of all objectives - is if I have a working website that lets me exercise the story in question. Letting broken untestable or unacceptable (meaning work that can not be acceptance tested) sit around is classic waste in the lean sense of the word.
Friday, April 17, 2009
Wednesday, April 15, 2009
Agile Contracting
Oh man, this topic is a doozy. Customers want to know how much something will cost and when it will be done without knowing what it is we are really going to end up doing. When you suggest that we will discover things and course correct, they stare at you blankly and ask if that means they are getting a discount. Customers generally don't want to have to think, and they want to shift the responsibility of designing their business model onto you, the contractor, because bless their hearts, they probably don't even have a business plan that would let them articulate their business and revenue model as it applies to the work they want you to do.
Having a consulting services based business means that your business consulting service model must be laced up and iron clad. You need to be the Delta Force that your customer is looking for. When you are a small business trying to keep all your customers happy, doing operations and support, figuring out your own revenue model that's required to support your existing client base, while at the same time figuring out how to grow your company to cover your new expenses that have emerged from your own success... it's really hard to do this. This is why most small businesses fail. An added challenge is when your business is small and there are limited numbers of partners, the partners tend to be the business development team, the sales team, the account execs, the PMs... and those roles have conflicting agendas that can make course correction in the middle of a project very hard. Sales people don't want to admit that the company's capabilities are a work in progress.
Here are some very cool articles on alternative contract models. The fixed cost, fixed scope, fixed time model ALWAYS fails without a change control officer pounding the client relentlessly, which often results in an unhappy client; on the other hand, if you don't pound them with change control, they eat into your margin, for us, typically by 50% of our margin. We desperately want to be fixed scope bucket, but varying content of bucket; we want to be fixed cost and fixed time, where we append the emerging requirements into a new bucket of cost and time.
http://www.sparkboxx.com/sparkboxx/types-of-contracts.html
http://alistair.cockburn.us/Agile+contracts
Having a consulting services based business means that your business consulting service model must be laced up and iron clad. You need to be the Delta Force that your customer is looking for. When you are a small business trying to keep all your customers happy, doing operations and support, figuring out your own revenue model that's required to support your existing client base, while at the same time figuring out how to grow your company to cover your new expenses that have emerged from your own success... it's really hard to do this. This is why most small businesses fail. An added challenge is when your business is small and there are limited numbers of partners, the partners tend to be the business development team, the sales team, the account execs, the PMs... and those roles have conflicting agendas that can make course correction in the middle of a project very hard. Sales people don't want to admit that the company's capabilities are a work in progress.
Here are some very cool articles on alternative contract models. The fixed cost, fixed scope, fixed time model ALWAYS fails without a change control officer pounding the client relentlessly, which often results in an unhappy client; on the other hand, if you don't pound them with change control, they eat into your margin, for us, typically by 50% of our margin. We desperately want to be fixed scope bucket, but varying content of bucket; we want to be fixed cost and fixed time, where we append the emerging requirements into a new bucket of cost and time.
http://www.sparkboxx.com/sparkboxx/types-of-contracts.html
http://alistair.cockburn.us/Agile+contracts
Friday, April 10, 2009
Rails has no application context
Something my developers have been complaining about lately is the difficulty in creating a generic dependency injection framework for a project with a lot of different plug-ins. I am asserting that there should be a generalized mechanism to set properties on a Rails domain model, rather than allowing plug-ins unholy access to reek havoc on my model objects.
We have a use case where we want to be able to inject different implementations for the same interface. The idea is that we are using attachment_fu to decorate models, but we want to be able to store attachments in a different persistence mechanism (currently local filesystem or Amazon S3). We've implemented a generic framework as an engine that depends on attachment_fu to handle the attachments. For a given client project, we'd like to able to inject the implementation for S3 or filesystem persistence, but since attachment_fu totally hacks our objects to bits, we have to write some exotic and smelly code to configure a given model to do what we want.
This is not the first time they've lodged this complaint, which is more or less that no matter how much (by much I mean well-defined, encapsulated, well designed OO etc) of an interface one of our in-house APIs surfaces, we are always already limited by the hackers who infiltrate our code with no contract. Plugins like attachment_fu offer no contract, they simply save the desperate ruby hacker from having to write lines of code, but the end result is a totally non-transferable hunk of smelly spaghetti code.
Perhaps Rails just doesn't support our over-arching design goal, which is the ability to write one piece of code to handle the use cases all of our clients ask for on every project we do. Maybe it's faster to just re-write the same code over and over. I called this article "Rails has no application context" because I am used to working in an environment like Spring where I can request any implementation I want through the application context. Objects communicate through an interface and there is no shared knowledge of implementation details. I want this same kind of service bus in Rails, where objects can register themselves and be available, and other objects can request an implementation of an interface and know that the required operations (eg save to storage mechanism) will be available without having any idea about implementation details of each other. Jaroslav Tulach calls this a "Teleinterface" which I think describes this situation accurately.
I've proposed to my development team that we create some kind of proxy for attachment_fu to rape as the sacrifical vigrin, rather than treat our whole domain model as an open harem. We must repel the godless Romans from our code. We can create some kind of proxy object that gets wired up with the attachment_fu hooks, and this object can then act as an API for our code to consume.
We have a use case where we want to be able to inject different implementations for the same interface. The idea is that we are using attachment_fu to decorate models, but we want to be able to store attachments in a different persistence mechanism (currently local filesystem or Amazon S3). We've implemented a generic framework as an engine that depends on attachment_fu to handle the attachments. For a given client project, we'd like to able to inject the implementation for S3 or filesystem persistence, but since attachment_fu totally hacks our objects to bits, we have to write some exotic and smelly code to configure a given model to do what we want.
This is not the first time they've lodged this complaint, which is more or less that no matter how much (by much I mean well-defined, encapsulated, well designed OO etc) of an interface one of our in-house APIs surfaces, we are always already limited by the hackers who infiltrate our code with no contract. Plugins like attachment_fu offer no contract, they simply save the desperate ruby hacker from having to write lines of code, but the end result is a totally non-transferable hunk of smelly spaghetti code.
Perhaps Rails just doesn't support our over-arching design goal, which is the ability to write one piece of code to handle the use cases all of our clients ask for on every project we do. Maybe it's faster to just re-write the same code over and over. I called this article "Rails has no application context" because I am used to working in an environment like Spring where I can request any implementation I want through the application context. Objects communicate through an interface and there is no shared knowledge of implementation details. I want this same kind of service bus in Rails, where objects can register themselves and be available, and other objects can request an implementation of an interface and know that the required operations (eg save to storage mechanism) will be available without having any idea about implementation details of each other. Jaroslav Tulach calls this a "Teleinterface" which I think describes this situation accurately.
I've proposed to my development team that we create some kind of proxy for attachment_fu to rape as the sacrifical vigrin, rather than treat our whole domain model as an open harem. We must repel the godless Romans from our code. We can create some kind of proxy object that gets wired up with the attachment_fu hooks, and this object can then act as an API for our code to consume.
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)