High velocity in software development translates to more than just profits. High velocity is the ability to respond fast to continuously changing conditions – either in the marketplace or on an ongoing project. Velocity enables innovation. Velocity reduces development costs. Any company that wishes to remain viable long-term needs to focus on velocity, and to ensure that velocity continually increases over time.
The term velocity has found increased usage in the agile development community of late, which is why I choose to use it here. However, my preferred term is actually throughput, which in terms of software development I define as the rate at which features [feature = unit of client-valued functionality] can be produced by a team or organization. Throughput is also the preferred term of process guru Eliyahu Goldratt of The Goal and Theory of Constraints (TOC) fame. Among other things Goldratt and the TOC movement have argued (and convincingly demonstrated) that focus on throughput as opposed to cost is a vastly superior strategy for increasing profits, among many other advantages. Indeed, cost focus turns out to be detrimental to the performance of virtually any business process, not to mention potentially destructive for employee relations. I’m aware that making this claim is akin to heresy in many CTO’s books, and in any case we don’t want to lose sight of the purpose of this post, so suffice it to say that if you want to make money now and in the future, then throughput/velocity has to be one of your top priorities.
Now if we compare our experience with the JFX-based Music Pinboard application with our experiences in developing RIA applications in alternative technologies, which include Swing, ULC, SWT/JFace, Ajax, Flex and others, then we are forced to conclude the following: The rate of feature development is impressively high with JFX. Here, roughly, is a list of features which comprise the Music Pinboard application:
- Enter search criteria
- Display artist name as title
- Display “related artists”
- Display associated albums
- Display associated videos
- Display associated pictures
- Scrolling through associated albums
- Scrolling through associated videos
- Scrolling through associated pictures
- Display and allow scrolling in a “display shelf”
- Video playback
- Consistent look and feel throughout
- Minimal response time enabled through parallel loading of items
- Download and run application
- Present application in a movable, shrinkable, closable window; closing window terminates app [this feature was introduced in Release 1.1 of MP]
So knowing the number of features (originally 14), developers (2-4) and the number of person days invested (20), it would not be difficult to compute a rate of feature development. Of course, the MP effort included learning time (discussed in Part I), so such a computation would not be terribly meaningful until a number of projects gone through the pipeline. The rate of feature development is clearly also influenced by feature complexity. This a further motivation for collecting productivity data over a series of projects over time, as only then can a meaningful average rate by calculated.
Nevertheless, we feel it is safe to say that JFX looks like a very promising technology when it comes to developer productivity. Certainly the development of equivalent functionality using Swing or equivalent object-oriented framework with no additional high-level support for Java2D effects (such as are provided in JFX) would have taken significantly longer.
And this can only be a good thing for the organization’s long-term financial health, as well as – let us not forget – our clients.
See also: JavaFX Script Productivity Part I of II: Learning.
Source: Photo by Joe McDonald