{
Steve Yegge has a post about the agile software development process. Gifted in wit and sarcasm, Yegge doesn't spare many punches in basically saying that "Agile" as is known as a process is basically about marketing and making money for consultants. He contrasts this with a lower cased "agile" which is what he believes Google (his employer) practices and others should.
A lot of comments seem to be coming back - resistance to Yegge's comments over at The Mindset because (and I agree with this) some of the things that are true for Google (working without deadlines) just can't be true for the rest of us. The Mindset also doesn't believe that the glossy, non-substantive Agile flies with most businesses. I'm not as optimistic as The Mindset since I have seen many an organization fleeced, but I do agree that most people aren't fools. Especially developers, the majority of which I've worked with are big skeptics.
Raganwald has the most interesting response I've seen so far: that it all comes down to people over process and a good team will succeed despite methodological strategy. Interesting because especially when it comes to Google, it seems like they take the cream of the crop so it would follow that they can be so lax with all the rock stars they have working there. Raganwald seems to fit into Spolsky's camp (maybe it was Raganwald's camp to begin with) where the equation is: Good programmers + working conditions == Great Software
Dare Obasanjo is pretty straight forward with how he sees Google:
"'smart people dicking around' type projects" versus "shipping code."
It doesn't get more plain than that now, does it?
Quite interesting especially since it wasn't long ago that I listened to Jutta Eckstein talking about Agility on Software Engineering Radio. The first thing out of her mouth was:
"People over process."
I think there's a lot of frustration in the marketing and money making of Agile but the finer details seem to have a lot of things that are great tactics in software development. "People over process" is a great way for the Agile methodology to begin itself since it allows for the Raganwald/Spolsky perspective but many of the communication things are good as well. What Yegge points out as "agile" in the sense of big rewards and incentives seem to have to do with compensation, not necessarily development methodology. Pair programming, as far as I know isn't a part of Agile but this is something I've never really seen as a full time approach. One thing I've been struggling with in my current project is the weight given to doing frequent releases in Agile. Because we started from scratch it doesn't make much sense and in this case we are departing from conventional Agile. However as the framework for the software begins to take form I'll push the team for more frequent builds that the client can look at. For now, scaffolding and putting things together for others takes far too much time and all the client would see is unfinished stuff that we are well aware is unfinished. Doing "SCRUM" meetings is another departure for us - we meet when necessary but there's enough on various plates to make meeting and percentages too much overhead.
In the end I find myself seeing truth in each person's perspective: Yegge is right about some of the dogma (whether it was intended or not is another question) some apply to Agile programming. The Mindset is right that those of us who don't work at Google don't have the luxury of working without a deadline. Raganwald is absolutely right on the importance of hiring. I did two interviews this week and that was... interesting. People, especially the caliber of whom work at Google, just aren't a reality for where I work. I include myself in that category since I'm not certain I'd fare too well in their hiring process.
}
Saturday, September 30, 2006
Wednesday, September 27, 2006
Do you test your work?
{
Most places I've been people would nod and look at you with disdain. But I can't think of a person I've met that is as rigorous as this. (Courtesy of CodingHorror)
Testing seems to have less to do with technical proficiency (what gets you the initial result) and more to do with tenacity. I'm hoping it's like a muscle too - the more it is exercised, the more anal retentive I'll become about the lengths I go to check my work.
}
Most places I've been people would nod and look at you with disdain. But I can't think of a person I've met that is as rigorous as this. (Courtesy of CodingHorror)
Testing seems to have less to do with technical proficiency (what gets you the initial result) and more to do with tenacity. I'm hoping it's like a muscle too - the more it is exercised, the more anal retentive I'll become about the lengths I go to check my work.
}
Monday, September 25, 2006
Eric Sink: Code Cover, Unit Tests
{
A good essay I finally got to last weekend is Eric Sink advocating code coverage. Code coverage is simply understanding how much of your code is executed within your application. For people like me who start off by sketching, revising, and honing their work, I'm sure an analysis of parts of dead code would be quite revealing.
But there were two other peripheral things about this essay that were very interesting to me. The first was a side comment Eric makes about how many lines of code he's written in the project:
The second thing that is interesting to me is that Eric always seems to have a side project of some kind. As a CEO of what seems to be a successful ISV this is impressive since many people I know in positions like that tend to lose their technical skills as they accumulate the managerial/strategic ones.
}
A good essay I finally got to last weekend is Eric Sink advocating code coverage. Code coverage is simply understanding how much of your code is executed within your application. For people like me who start off by sketching, revising, and honing their work, I'm sure an analysis of parts of dead code would be quite revealing.
But there were two other peripheral things about this essay that were very interesting to me. The first was a side comment Eric makes about how many lines of code he's written in the project:
"This library consists of 12,341 lines of algorithms, plus 5,819 lines of unit tests."What's interesting about this to me is that Eric, who is a developer I completely respect, is writing about a line of code in unit tests for every couple of lines he is writing as actual project. Ever since I became the resident nag of unit tests, trying to lead by example, I have come to realize just how much discipline it takes to have serious test coverage. As time has passed I've been happy with our choice since it's been helping us release much steadier versions of our software. I've also learned a lot about how to test our code, which I'll hopefully find time to share on this blog later.
The second thing that is interesting to me is that Eric always seems to have a side project of some kind. As a CEO of what seems to be a successful ISV this is impressive since many people I know in positions like that tend to lose their technical skills as they accumulate the managerial/strategic ones.
}
Saturday, September 23, 2006
Visual Studio Environment Settings
{
First it was Scott talking about his Visual Studio environment and then it was Jeff posting some of his own settings and a website to download customized VS.NET Environment settings.
I'm usually a bit boring when it comes to things like this - I used to like the courier font at 10 or 8pt since I'm used to laptops with next to nothing in coding real estate. Otherwise everything was default.
But I've taken to Jeff's ZenBurn settings quite a bit.
I hope the IDE Hot or Not site takes off; it would be interesting to see what some other people's settings look like. Who knew Visual Studio could have a Toyota Scion style effect and bring out a person's personality?
}
First it was Scott talking about his Visual Studio environment and then it was Jeff posting some of his own settings and a website to download customized VS.NET Environment settings.
I'm usually a bit boring when it comes to things like this - I used to like the courier font at 10 or 8pt since I'm used to laptops with next to nothing in coding real estate. Otherwise everything was default.
But I've taken to Jeff's ZenBurn settings quite a bit.
I hope the IDE Hot or Not site takes off; it would be interesting to see what some other people's settings look like. Who knew Visual Studio could have a Toyota Scion style effect and bring out a person's personality?
}
Tuesday, September 12, 2006
Unit Testing
{
I've worked on lots of projects but never been in a position to push everyone to have a unit test for all the important pieces of the application.
Pushing for unit tests makes me feel like the resident nag, especially when it goes beyond making the proclaimation that we'll approach the project in this way and leads into my sitting down with people pointing out code that seems to work but isn't covered by any unit tests. I'd be inclined to follow up everyone's code with unit tests they could have written myself, but it's too much work for a single person.
Another difficulty is that while I get the concepts behind unit testing, writing a good unit test is proving more thought provoking and difficult than just the idea of having a test that covers a method call. Most of the articles about unit testing talk about it in terms of methods that don't seem to have as much complexity or methods that don't leverage external resources. It's easy, with articles like that to have an example of a method that adds two numbers and then has a test that asserts that two values added have a correct result.
In our case, we've got a somewhat large database that we are utilizing in most methods making how/what we test for much more tricky. For example, if we have a method:
public LoanApplication GetApplicationById(int appId){ ... }
What's the best way to test it? Thus far we've got the following things:
1. Make sure the result is not null.
2. Compare properties against database query (with a tested database library).
Our test for that method may look like the following:
[TestMethod]
public void TestGetApplicationById(){
AppService appService = new AppService();
Assert.IsNotNull(appService.GetApplicationById(1));
LoanApplication testLoanApp = appService.GetApplicationById(1);
DataTable testTable = db.GetDataTable("select * from App where AppId=1");
Assert.AreEqual(testTable.Rows[0]["AppId"], testLoanApp.AppId);
// other fields test
}
How does one get tests like this right?
}
I've worked on lots of projects but never been in a position to push everyone to have a unit test for all the important pieces of the application.
Pushing for unit tests makes me feel like the resident nag, especially when it goes beyond making the proclaimation that we'll approach the project in this way and leads into my sitting down with people pointing out code that seems to work but isn't covered by any unit tests. I'd be inclined to follow up everyone's code with unit tests they could have written myself, but it's too much work for a single person.
Another difficulty is that while I get the concepts behind unit testing, writing a good unit test is proving more thought provoking and difficult than just the idea of having a test that covers a method call. Most of the articles about unit testing talk about it in terms of methods that don't seem to have as much complexity or methods that don't leverage external resources. It's easy, with articles like that to have an example of a method that adds two numbers and then has a test that asserts that two values added have a correct result.
In our case, we've got a somewhat large database that we are utilizing in most methods making how/what we test for much more tricky. For example, if we have a method:
public LoanApplication GetApplicationById(int appId){ ... }
What's the best way to test it? Thus far we've got the following things:
1. Make sure the result is not null.
2. Compare properties against database query (with a tested database library).
Our test for that method may look like the following:
[TestMethod]
public void TestGetApplicationById(){
AppService appService = new AppService();
Assert.IsNotNull(appService.GetApplicationById(1));
LoanApplication testLoanApp = appService.GetApplicationById(1);
DataTable testTable = db.GetDataTable("select * from App where AppId=1");
Assert.AreEqual(testTable.Rows[0]["AppId"], testLoanApp.AppId);
// other fields test
}
How does one get tests like this right?
}
Monday, September 11, 2006
Testing Frameworks: NUnit up one
{
After spending a long time without having the ability to impose "testing" in the projects I was working on, I'm now in the position as lead developer to make testing a part of our development process.
Last week I went back and forth with either using NUnit, which I'd be more inclined to do on my own versus Visual Studio Team's built in testing capability. I chose Visual Studio just because it would be easier for team members to get to; I can't look over everyone's shoulder and force them to write tests but I can make it as easy as possible to encourage the behavior.
Before doing so I did a search to try to see if there were major differences between NUnit and Visual Studio's testing - I don't remember anything notable but today, just my luck since we've gone full force in the Visual Studio direction, I find a post complaining of lack of functionality in Visual Studio's test framework vs NUnit.
}
After spending a long time without having the ability to impose "testing" in the projects I was working on, I'm now in the position as lead developer to make testing a part of our development process.
Last week I went back and forth with either using NUnit, which I'd be more inclined to do on my own versus Visual Studio Team's built in testing capability. I chose Visual Studio just because it would be easier for team members to get to; I can't look over everyone's shoulder and force them to write tests but I can make it as easy as possible to encourage the behavior.
Before doing so I did a search to try to see if there were major differences between NUnit and Visual Studio's testing - I don't remember anything notable but today, just my luck since we've gone full force in the Visual Studio direction, I find a post complaining of lack of functionality in Visual Studio's test framework vs NUnit.
}
Wednesday, September 06, 2006
Monday, September 04, 2006
REST for the wife
{
When I was teaching I'd love to ask a person to give me an explanation of a technical concept as though I was a 13 year old. It's easy to memorize the acronyms but it's much harder to unpack them, especially with enough understanding to simplify them for people that have no assumptions with respect to the concept.
Ryan Tomayko, in this case, has done an amazing thing: read along as he explains REST to his wife (who we may assume as an intelligent but non-technical person).
}
When I was teaching I'd love to ask a person to give me an explanation of a technical concept as though I was a 13 year old. It's easy to memorize the acronyms but it's much harder to unpack them, especially with enough understanding to simplify them for people that have no assumptions with respect to the concept.
Ryan Tomayko, in this case, has done an amazing thing: read along as he explains REST to his wife (who we may assume as an intelligent but non-technical person).
}
Rumble in the Jungle
{
There is a saying among Africans: "When two elephants fight, it's the grass the suffers most."
But fortunately this doesn't apply to the web; when two giants go at it, we get to tune in and watch the blow for blow, entertained.
On Friday Joel Spolsky published The Language Wars, in which he discussed an approach to picking a language/platform for application development. I believe his point had more to do with picking a well trodden path for a development project, as well as having an architect with lots of experience with your chosen platform/language. Along the way, however, he said:
The rest you can read in the post but these comments sparked a fire from Ruby on Rail's inventor, David Heinemeier Hansson who retorted quickly on his blog that Joel was full of FUD. It's an interesting exchange but Hansson points out that Joel's final thrust is about a language called Wasabi that is used at Fogbugz and completely outside the "well trodden path" or "proven platform" category he seems to espouse at the outset of the article.
Soon after the rebuttle was posted there seemed to be a lot of people who thought Wasabi was a joke that Joel was using to wink at his like-minded classicists with while stoking the fire of the Ruby hipsters - so much so that many posted that they "got the joke" maybe in part to feel like they were the clever Ivy League programmers they assumed Joel left the easter egg for.
But they were wrong, and Joel followed up with a post in which he confirmed the existence of Wasabi, while backing away a bit from controversy by not rebutting the rebuttle.
All in all, it was an interesting friday evening following this story around. I never assumed Wasabi was an inside joke; Joel's mentioned many times that Fog Creek had a compiler they used to generate Fogbugz code in PHP and VBScript amongst other languages. I didn't understand the big fuss on the part of Heinemeier Hansson either and others - the concept of a domain specific language written in something doesn't pull away its platform underpinnings. If anything the platform is a safety net of sorts. But beyond this, the most important piece of the puzzle is Joel's second point: an architect is absolutely necessary for big, enterprise software (in order to do a good job).
On the other hand I find Joel's skepticism toward Ruby on Rails as premature as the blind enthusiasm of many. There is a lot of room between "Serious Business Applications" and college projects. Many business applications are not mission critical banking - I just participated in a rewrite of a sales project management platform that could have been Ruby on Rails fodder. If anything there's going to be better, smarter business development tools as a result of the good ideas that Rails has fostered.
Time to stay tuned to the aftermath in the blog/web world.
}
There is a saying among Africans: "When two elephants fight, it's the grass the suffers most."
But fortunately this doesn't apply to the web; when two giants go at it, we get to tune in and watch the blow for blow, entertained.
On Friday Joel Spolsky published The Language Wars, in which he discussed an approach to picking a language/platform for application development. I believe his point had more to do with picking a well trodden path for a development project, as well as having an architect with lots of experience with your chosen platform/language. Along the way, however, he said:
... and a handful of platforms where The Jury Is Not In, So Why Take The Risk When Your Job Is On The Line? (Ruby on Rails). Before you flame me, Ruby is a beautiful language and I'm sure you can have a lot of fun developing apps it in, and in fact if you want to do something non-mission-critical, I'm sure you'll have a lot of fun, but for Serious Business Stuff you really must recognize...
The rest you can read in the post but these comments sparked a fire from Ruby on Rail's inventor, David Heinemeier Hansson who retorted quickly on his blog that Joel was full of FUD. It's an interesting exchange but Hansson points out that Joel's final thrust is about a language called Wasabi that is used at Fogbugz and completely outside the "well trodden path" or "proven platform" category he seems to espouse at the outset of the article.
Soon after the rebuttle was posted there seemed to be a lot of people who thought Wasabi was a joke that Joel was using to wink at his like-minded classicists with while stoking the fire of the Ruby hipsters - so much so that many posted that they "got the joke" maybe in part to feel like they were the clever Ivy League programmers they assumed Joel left the easter egg for.
But they were wrong, and Joel followed up with a post in which he confirmed the existence of Wasabi, while backing away a bit from controversy by not rebutting the rebuttle.
All in all, it was an interesting friday evening following this story around. I never assumed Wasabi was an inside joke; Joel's mentioned many times that Fog Creek had a compiler they used to generate Fogbugz code in PHP and VBScript amongst other languages. I didn't understand the big fuss on the part of Heinemeier Hansson either and others - the concept of a domain specific language written in something doesn't pull away its platform underpinnings. If anything the platform is a safety net of sorts. But beyond this, the most important piece of the puzzle is Joel's second point: an architect is absolutely necessary for big, enterprise software (in order to do a good job).
On the other hand I find Joel's skepticism toward Ruby on Rails as premature as the blind enthusiasm of many. There is a lot of room between "Serious Business Applications" and college projects. Many business applications are not mission critical banking - I just participated in a rewrite of a sales project management platform that could have been Ruby on Rails fodder. If anything there's going to be better, smarter business development tools as a result of the good ideas that Rails has fostered.
Time to stay tuned to the aftermath in the blog/web world.
}
Subscribe to:
Posts (Atom)
Posts
