Digging a Hole and Covering it with Leaves — The Software Development Version
Whenever I hear the plan uttered (and in my Wall Street consulting days, I heard this a lot), that we should build an HTML (or Flash) prototype, impress the client and then fill in the back end, an unwanted image comes to mind. We're digging a hole (the missing 80% of the back end) and covering it with leaves (the HTML prototype) in the hopes that the client will fall in (impressing the client).
No, this isn't a rant about HTML, Flash or paper prototypes. Those have their place, to be sure. We use them every day in our own software development practice, but they have a short lifespan -- usually less than an iteration on the way to delivering the actual feature that it is prototyping. But when the prototype takes on a life of it's own and becomes a long-term deliverable, that's when you run into problems. What are these problems? They aren't as numerous as fall leaves, but there are plenty.
Topics: Agile Development, Prototyping
Agile Fundamentals: The Feedback Loop
When you improve a little each day, eventually big things occur. -- John Wooden
A few weeks ago I had a discussion with some colleagues on the adoption of Agile within large corporations. The consensus was that Agile was almost always adapted rather than adopted -- that is, companies exclude those practices that conflict with corporate culture, modify those that seem too impractical or wasteful, and sometimes substitute those internal practices that seem a decent and familiar substitute.
Various schools of Agile thought have different reactions to this adaptation, all negative. The XP folks particularly don't like it.
These [thirteen] practices support one another...and thus care should be taken when modifying any of them, or deciding not to include one or more of these practices in a project.
I agree that it definitely helps to follow a particular Agile approach closely in the beginning. Once you have the basics down, you can start to improvise. But it helps knowing the fundamental principle which, in my opinion, underlies all of the agile practices, no matter what the flavor. So, the first three commandments of Agile software development are:
- Feedback loop
- Feedback loop
- Feedback loop
Topics: agile, Extreme Programming, Feedback Loop
GWTUML - Just Enough UML for Wikis
Florian Mounier has spent the last six months developing GWT UML, a slick little UML diagramming tool written in, obviously, GWT. It's smooth, good looking, supports class, object and sequence diagrams. You can save your diagram as a url or export it to an SVG. You wouldn't try to do model driven development with it, but for embedding in a development wiki, this thing could rock.
You can find more information at the google code project and check out a demo here.
Summer Software Development Internship
We're starting a software development summer internship in our Chicago office this year. If you're a college junior, senior or recent graduate who want to learn the agile/OO development ropes while developing really cool products and services and earning $20/hr per hour (you should pay for the privilege, right?), give the internship posting a look here.
Are You Building an Application or an Antique Web Framework?
A few years ago, a friend of mine asked me to help him estimating the conversion of a client/server application to the web. He came armed with a spreadsheet of features, I came armed with Ibuprofen and a red pen.
My usual approach to estimating involves breaking down the features into things that can be implemented by a pair of developers within a two week period. I give these a complexity factor of 1-5, then run them through an empirically derived formula to come up with an estimate in terms of person-iterations. (It's actually a little more complicated than that, but this is the main effort). Getting the count and size of these mini-features right is the key aspect of this technique. His spreadsheet had almost 300 features listed, and so we settled in for a day of fun.
Continue reading »
Topics: agile, Estimating, Requirements, UXD
The Origins of Software Engineering Economics — You are Ron Turcotte
Between the idea / And the reality / Between the motion / And the act / Falls the Shadow. -- T. S. Elliot
We have a particular way of developing software. We practice it until we're like the Harlem Globetrotters and your software project is like the New Jersey Generals -- defenseless against our iterative, pair programming, test and user experience driven weave. We didn't just happen upon this approach haphazardly; rather, we evolved it through trial and error and shameless adaptation of other software developers' ideas. It represents our answer to a number of the critical questions of software development. Three of those questions (that you'll hear us refer to over and over again) are:
- If bugs get more expensive to fix the longer it takes to identify them, how do we catch them as quickly as possible?
- If most bugs in a mature application are caused by missing or unclear requirements, how can we close this communication gap?
- If 50%-70% of the cost of most software is spent in maintenance as opposed to the original development, is there a way to spend a little more up front to improve that ratio?
So where do these nuggets of software development wisdom come from? From a Software Engineering Classic called Software Engineering Economics by Barry Boehm. Like most of these classics, such as The Mythical Man Month, its findings and advice are widely accepted yet honored mostly in the breach. Yet its empirical findings about bugs, maintenance costs and unclear requirements still govern most of what makes the software development landscape so treacherous for product managers.
Topics: Agile Development, Secretariat, Software Development
IE8: That Sinking Feeling
When a new browser comes out, like IE8, the verdict usually rolls in over the course of a few weeks as our QA testing on various web projects bumps up against its limitations. It's too early for us to render a verdict, but the signs have not been good and continue to be negative.
The evidence continues to trickle in. Louis-Rémi Babé weighs in with his grim assessment:
- The JavaScript performance on IE8 is still lousy.
- Useful tags such as
<canvas>, <svg>, <video>are still missing. - CSS3 is minimally supported. (I agree that this is good news for web developers since we get to charge more money for all the extra effort that goes into IE8 work.)
To top it all off, Vector Markup Language (VML) is freshly broken. It's one of those sad and frustrating stories. Read up on it here and feel sorry for all of those framework developers who have to crowbar in several hacks for all of the garbage in IE8.
Bean of the Devil: Tally-Ho CMS
Last time we came this way we looked at the misuse of a getter in the java.io.File. Not that it was wrong to have a getter in File, just that it led to misuse of that information in a UI control to determine what file encoding needed to be used to store the model.
This time we are looking at the Tally-ho CMS project. This is perhaps a more pernicious example of the shortcomings of getters and setters. We're not having to remember rules about changing state here (that's for an upcoming post), but we are exposing the implementation details and thus repeating code and making our application harder to change.
There are many places where ArticleBean is unpacked in the application. Here are just two examples.
Continue reading »
Topics: Design Patterns, OOAD, OOP, Structured Design
Week in Review
Some interesting posts from around the blogosphere:
- The GWT Plugin for Grails has been stuck in version 1.4.x of GWT for forever. Michael Galping has published a two part (one and two) series at IBM Developerworks on integrating Grails and GWT 1.5.3. Extensive, well illustrated with full source code available for download.
- InfoQ has published an interesting conversation about Ajax and COMET versus HTML Web Sockets, i.e. hacky COMET versus real bi-directional communication mechanisms between the server and browser.
- UXDesign.com has a concise summary of an Alan Cooper Interview video from 2008. User Experience Design, baby!
- David Hamill has some provocative musing on the difference between usability and user experience design. Not sure I agree with everything he has to say, but it's a question that comes up often and is worth thinking about.
- A bit older, but I just came across it: the original ScrumMaster, Jeff Sutherland, has an interesting article about ROI and incremental development. The conclusion? Incremental is better.
But seriously, we don't have enough rigorous thinking and writing about how good design and process reduces the cost of software in the long term (while perhaps increasing it in the short term).
These were some of the posts that I found valuable over the last week. Please share yours in the comments.
IT Mill Toolkit 5 out of Beta
With the release of IT Mill Toolkit 5.3.0, the server-side RIA framework is now ready for production. I announced the initial release of 5.0 back in December of 2007. Since that time, IT Mill 5 has gone through several revisions and the release of GWT 1.5 (which means you can use Java 5 now on both the client and the server). As a reminder, server-side RIA frameworks let you write your app completely in the server and uses a client-side Ajax engine to render the interface. The nice wrinkle with IT Mill is that both the server side and the client side are written in Java, so if you want to add a component, you don't have to break out the JavaScript (see the extensive and high quality reference manual for details on how to develop your own custom components in GWT). If you're a Java shop, that's got to be a good thing.
Topics: Ajax Development, Ajax Frameworks, GWT, IT Mill Toolkit, Java, Server Side
Agile Development for Product Managers: Why Agile Testing Rocks
All software has bugs. I don't care if you're Apple, Microsoft, IBM, or a smaller, leaner ISV. Your software has bugs in it. Once you accept this fact, that into each software product a little crap must fall, it becomes clear that what differentiates one software development organization from another is how they manage those bugs. What do you do to prevent them in the first place, find them, fix them, measure them, celebrate their squashing?
Most of the developers at Pathfinder Development are old hands. We've been around the block a few times. We've worked on quite a number of software projects over the years. We've all gravitated toward agile development not because it's the latest buzzword, or because it feels so good (though it does when it's done right), but because everything else feels so bad.
Take testing, for example. Testing girds you, the product manager, for the moment of truth -- deploying or shipping a new release. In the monolithic or waterfal processes, we would often wait until the end, after all of the development was done to "QA" the application. Often you'd throw in some performance testing to see if this monstrosity you'd just built would actually handle the load you were going to throw at it.
After weeks or months of testing, fixing, hoping, praying and integrating, you'd finally deploy. Odds are you'd ship with some pretty serious bugs. But the quality of the software, in terms of bugs and errors, was pretty poor and the expense and effort of the developers fixing the bugs was akin to the contractor applying spackle to a drywall that was more hole than whole.
Let me go through some of the testing we do today, what the previous alternative was, and what the benefit for your product is.
Bean of the Devil: Arguing the Affirmative
I've gotten lots of feedback, much of it asking "what's the alternative?" to using beans and getters and setters. I'll make a deal with my skeptical readers. I'll argue the negative, with examples, if they argue the affirmative. In other words, you show me some places where you can't get around using getters and setters and I'll show you all sorts of places for the next few weeks, from real open source projects, where people have screwed the pooch with unnecessary getters and setters.
Topics: Antipatterns, Beans, Design Patterns, Java, OOP
Bean of the Devil: Why Getters, Setters and Such are Evil
I felt like I'd already gotten this rant out of my system, but every time I come across the object oriented wreckage that the Java Bean and it's decendents have wrought, I get all heated up. The problem is, simply stated, that the getters and setters that get used for things like system boundaries -- Hibernate for persistence, Spring for dependency injection, Java Beans for UI components -- end up being misused for things that break basic OO principles.
Topics: Design Patterns, Object-Oriented, OOP
Are We Engineering Software or People?
I had a nice little vacation this past week in Los Cabos. It's always sunny, 80 and it never rains. Very nice. My wife and I had another installment of our long running discussion called "Computer Science is not a science." My wife is a real scientist with a Ph.D. in physical chemistry, and so she has a bit of a chip on her shoulder about the whole "science" thing. It's a one-sided discussion because I agree with her. Computer science is not about experiments and the scientific method, it's about three or four different and disparate areas -- mathematical computer science, AI or clever algorithms, chips and clock logic, and software engineering.
Then she told me that she thought of me more as an engineer. That got me thinking. Am I really an engineer?
Estimating Bugs and the Complex Behavior of Simple Systems
One of the bitter consolations of mathematical Computer Science is that we can demonstrate that applying algorithms to analyze algorithms is a largely fruitless task. It starts with the halting problem (can we write a program that takes a program as it's input and determines whether that program halts on all inputs) and goes on from there. The proof is by contradiction and -- like most "assume not" proofs -- is largely unsatisfying, i.e. it doesn't construct anything useful that you could apply to other problems. As Professor Herstein once told me in undergrad algebra, "Kappe: assume not assume not."
That's one of the theoretical underpinnings of why some software bugs are so hard to detect and fix; in a large system, automatically diagnosing bugs is akin to solving the halting problem. But what if we just try to solve this problem for a really small subset of programs? Well, first, it would have to be a really small subset. And second, even with very simple systems, answering questions about correctness, such as "does it halt," can be surprisingly difficult.
Topics: Bugs, Estimating
About Pathfinder
Follow the Blog
-
Get a monthly update on best practices for delivering successful software.
Subscribe via email
Subscribe via RSS
Categories
Topics
Archives
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Blogroll
Recent
- Elements of Testing Style
- Aesthetics and Web Design
- Asterisk-Java Testing with Groovy
- 3 Misuses of Code Comments
- Fluently NHibernate
- Digging a Hole and Covering it with Leaves — The Software Development Version
- The Importance of User Experience - Do You Understand It in Your Bones?
- Writing Your Own Protocol With NSURLProtocol
- What’s In Your Dock: iPhone edition
- Feature Fatigue





