Model Driven Development in an Agile world
Posted by Ben Menesini in Uncategorized on June 1st, 2009
Wednesday was the monthly Northern Nevada Software Developers Group meeting (at Buckbean Brewery, no less!). The speaker was Doug Holland, who’s a big advocate of Model Driven Development, and tools that support it.
In a nutshell, and I apologize if this is a naive view of it, Model Driven Development is based upon up-front requirements gathering and full UML specifications before writing code. In an ideal world, the UML would then be turned almost directly into code using Visual Studio 2010 tools, Rational Rose, Borland Together, or some other modeling-to-code tool.
The concept of gathering such a full set of requirements all up front scares the hell out of me. I’m an Agile proponent - concepts like Just Enough, Just In Time, YAGNI, and collecting user stories in short iterations are more up my alley, because I’m of the mind that requirements change during development. This is especially true in the case of miscommunication between developer and customer, and, sorry Doug, I just don’t understand how Model Driven Development considers this kind of flexibility. The development community is turning to an Agile World, and the old waterfall methods are dying away, along with full UML specs for driving development.
Now, let me back up for a minute. UML, and using models in your development is an awesome way to communicate ideas, if used properly. I feel that Model Assisted Development and Agile processes go hand in hand. Keep your usage tempered - it’s easy to overdo specification and requirements gathering.
UML is useful for two things in my mind:
- Documentation - Detailed models make it much easier for new developers on a project to gain domain knowledge. That being the case, generate the models from the existing code, don’t create it separately. Also, make it easy to generate it more than once - your system is going to change, even if it’s as infrequent as a major version.
- Feature requirements - Okay, you need a database, and an ORM, and five other things. Draw it out, put it together, but don’t worry about the details unless they’re really that unclear. You’ll find improvements to your design as you go. The model should just be an idea of what you’re building - never develop strictly against the model, or you’ll be developing a lot more than you need, and you’ll never take advantage of improvements to design that you’ll find while developing. I’m making a distinction here between “feature” and “project/program”, with a feature being a small part of the application.
Use modeling tools to support a process - just don’t waste time and effort making them the process.
Palm Pre’s app library should be just as good as the iPhone’s
Posted by Ben Menesini in Mobile Development on May 29th, 2009
To put it simply, I just don’t see the Palm Pre having that much of a problem catching up to the number of useful applications that the iPhone has.
Don’t take this as trolling - my fiancee has an iPhone, and I’m incredibly jealous with my old HTC TyTN not being able to accomplish even web browsing in half the time she does. I have admiration for what the iPhone can do and has accomplished in the marketplace. However, these things don’t take away from the fact that the Palm Pre is positioned to present a challenge to Apple in the smartphone arena.
I have one reason for this, and it’s one that’s going to make developers cringe (if only a tiny bit): JavaScript.
Sure, the iPhone has caused a few devs to learn Objective C and go out and buy a Mac Mini or Macbook, but both of these things require an investment of time and money. With the Pre’s software being written within their JavaScript framework, Palm has opened the door to a ton of software and web developers on hardware that developers are more likely to own.
Granted, we won’t be seeing large-scale 3D games on the Pre - it is, after all, merely JavaScript. What we will see immediately is an emulation of the most useful iPhone applications, and I wouldn’t be surprised to see them pop up at an incredible rate for the Pre.
The down side, however, is exactly the same as the plus side. JavaScript, while easy to learn and get into, also makes it easy to write unmaintainable code, and not everyone writing apps for the Pre will be a true developer (though, the same could be said for the iPhone, I suppose). I shudder at the thought of the various qualities of the applications coming to the Pre, but hopefully in the eventual sea of apps, there will be some treasures to be found.
What are you doing for your Customers?
Posted by Ben Menesini in Agile, Customers, Development Practices, Process on May 20th, 2009
I don’t necessarily mean the people who pay you, but they could be.
Customers, in this case, are the people who give you work to do. Call it a “customer” in an agile sense, or just call it your clients, it’s the same thing. These are the people who keep you employed - the people who depend on you being able to make critical decisions about what new features are provided to them and when. What have you done for them lately?
Today, I asked my customers about what makes their jobs tedious. I wanted to know about what little thing they do that could be taken away so that they can more effectively do their jobs. I wasn’t after anything big - after all, I have large responsibilities to take care of - but what I was after was a little project. Maybe this little project was just something that could be done in a few hours, maybe two weeks, but a small project nonetheless.
With the one simple question, “Are there any little programs or tools we could create to make your jobs easier?”, I’ve provided a ton of value to my customers in a couple of ways. First, it reminded them that I care, that I recognize that they’re the people that make me useful. Without keeping them in mind, I’m just off writing code that no one has asked for. Second, I learned several things about what my customers value. It’s sometimes a very difficult thing to discover without deep prodding, but even if it’s as simple as, “I think the logo on our app should be a tiny bit bigger,” and it’s met with agreement, then that’s what matters, regardless of what language, platform, efficiency, or other issues you might be having with your software. If the people using your software don’t find it friendly, useful, or helpful, it’s a waste of time and effort because they won’t use it or won’t trust its output, plain and simple.
So, ask your customers, “What can I do to make your job easier?”, because in the end people are the reason we write software, not processes or puzzles..
The Confusion between Behavior Driven Development and Test Driven Development
Posted by Ben Menesini in Development Practices, Uncategorized on May 17th, 2009
I’ve come to the realization that I need some sort of open source experience in my portfolio, whether it be in Java, Python, Ruby, or something new to me entirely. I started this not-so-ridiculous little adventure by scouring lists of open source projects, hoping to find something with an ample amount of low-hanging bugs to cut my teeth on. There are some really great projects out there, all a little broken in their own special ways, but a particular inspection into BDD tools in Python led to more than a few posts from developers who criticize the movement as a whole, saying they’ve already got TDD tools, and they can achieve the same thing without anything new. To them, I say, “Heresy!”, but also, “Of course!” Confused?
They’re right - they don’t need anything new. BDD is a hype-machine, and TDD allows for the kind of flexibility that lets people do BDD using TDD tools.
I only hope they understand why they’re right, and it’s about more than mere semantics. The way I see it is that behavior driven development is about developing the correct code, while test driven development is about developing the code correctly. In other words, it’s about the “what” not the “how”. Just like how you can write the same method in many languages, you can do the same types of tests using either tool - it’s just a matter of whether or not the tool is designed for the job. It’s easier for me to think of behavior driven code as being focused on acceptance and integration tests, using mock objects where appropriate, and leaving test driven code to be focused on unit tests, because that’s where the language lies.
Behavior driven development is highly anchored upon getting the words right. It’s about writing tests that can document the code you’re working on, and tests that can immediately show value to a non-programmer. We’re talking about defining functionality based on business situations rather than programming situations, or better described as “The stale circus peanuts should come out of the machine when I ask the vending machine for them” rather than “When I hit C7, I shouldn’t have an integer overflow error”. To be absolutely defining, we break down behavior driven tests into stories and scenarios.
A typical story might look like this:
As a giant robot attack panda,
I want to deploy laser beams from my eyes,
So that the buildings I look at can be destroyed.
I’ve defined who the actor is, what the code should be able to do in the end, and why we’re doing it. It’s the essence of your customer requirements, and the reason we can’t have nice things we’re writing the code in the first place.
The second semantic difference for BDD code is that we dive into scenarios of the development situation rather than a mere test of how the code runs. They’re not just tests for the sake of testing, which TDD can sometimes feel like, and it’s easy to love once you’ve done it a few times.
Given that my laser beams are charged,
When I call the destroySuburb method,
Then the suburbs in my path should be left in ruins.
Given, When, and Then give you all of the power in the world, and in Ruby’s RSpec, and to a lesser extent, Java’s JBehave, this is running code. This isn’t complete code by any means, but it gets the ball rolling.
Like I mentioned before, the entire reason this is different and valuable when considering TDD vs BDD, is the language we use. Rather than “CheckOverflowCondition()”, which isn’t a terrible method name for a unit test, the test case itself describes what’s going on. We’re setting up a situation and testing our methods against it - using mock objects when we can. It’s testing implementation, but more importantly, it’s also testing intent. When a test can tell you that you don’t need to write the code you were just about to, it’s a beautiful thing.
You can do this with TDD tools. Of course you can - just give your unit test some ungodly long method name and keep in mind the same principles. You can also do calculus without a TI-89, and sometimes it’s fun to do so, but it’s not something I like to do on a regular basis. For me, it helps to separate my acceptance, integration, and user/customer driven tests from my unit and implementation tests - as I mentioned before, it’s all about writing the right code versus writing the code the right way. Do both - you’ll find yourself a balance and thank yourself later.
I’m Back!
Posted by Ben Menesini in Uncategorized on May 14th, 2009
Silverstripe, while I feel it’s a great CMS system, really isn’t built for shared hosting. Caching problems galore has forced me to move back to Wordpress, which I must say has improved a significant amount since the last time I’ve touched it.
Be ready for some new posts, and some inevitable slacking off. Here we go!
