Thus far in this series, The Art of Accurate Software Estimation, I have presented a wide breadth of the complexities and challenges that we face in presenting a software estimate. In this post, I am anxious to discuss the subject of how choosing software frameworks and estimating with those frameworks in mind can help simplify estimation. I am using a wide application of the term software framework and am generally including anything from small libraries as well as the larger architectural underpinnings of a application.
Software architecture is a complex balance of design decisions versus the long term benefit gained from that design. Software frameworks aim to facilitate the design and development process by laying a foundation from which developers are able to devote more of their time to meet software requirements. Frameworks are intended to free up time and effort so that less time is spent on the low-level details of providing a working system. For example, a team seeking to build an enterprise online banking application would be best to start with an established framework that handles the mechanics of http requests, state management, logging and data access early on, thereby allowing them to focus on writing code particular to banking.
On the one hand, the more functionality the framework provides, the more time developers can spend on writing features that contribute to the application’s core value proposition. On the other hand, this desirable goal needs to be balanced very heavily with the reality that too much framework leads to its own overhead of complexity, code bloat, and learning curve. The unfortunate reality of software development is that there is truly no “one size fits all” development framework. Most often, frameworks with the most out-of-the-box functionality inherently have the most complexity, bloat and learning curve. These issues are not to be taken lightly. Complexity and bloat are both issues with the software itself, whose symptoms surface to the end user as system instability, lacking performance, or just generally being very buggy. To the development team these issues surface as extremely fragile, difficult to understand, and time consuming or nearly impossible to modify or improve. Then there is something I call overreach, where out-of-the-box functionality is being twisted or over extended to do something that would have been easier or in many ways better without the framework.
There are many considerations and potential pitfalls in selecting the right mix of frameworks. I’ll get into some of those specifics in a bit, but first, let’s consider some of the benefits in finding this elusive concoction.
- Estimates get simpler with more of a formulaic feel. Going back to the concept that more time is invested in actual requirements and less on the mechanics, means that the team is estimating a smaller code footprint to deliver a feature set. Having experience with the frameworks in use also provides a frame of reference as to how long development will take.
- There is a greater standardization of code and productivity between developers. All developers work at different paces and write in different styles. Increased use of frameworks allows for the differences in developer ability, knowledge base or coding style to be more accurately anticipated. This also provides the added benefit of reduced ramp up for new team members since there is more cohesion in the code base.
- A communal sense of code ownership arises. This is the concept where greater confidence and familiarity with the frameworks in play encourages any team member to jump into any feature set, which again increases the ability to anticipate level of effort and reduce risk throughout the implementation cycle.
Things to Look for in Frameworks
- The best frameworks are grown organically from long term iterative re-factoring, where developers identify and extract the elements of reusable and time tested solutions and patterns.
- Successful frameworks are usually lighter weight and focus on more speciality. Again, the one-size-fits-all framework is a myth that should be avoided.
- Clean separation of concerns. Clean separation of concerns is developers talk about loose coupled design where code is modular, plugable and therefore easily reusable. In many cases a good approach for clean separation is finding frameworks that specialize in very specific behaviors. Case in point, AutoMapper does nothing but maps typed object properties from one to another. AutoMapper is exceptionally good at doing this, and uses IL generation making it extremely fast. Not only does this specificity of the framework guaranteed separation, but it also speaks to how well it is written.
- Few or No External Dependencies.
- Enthusiasm in the user base. Do some digging to find what the support community looks like, and how die hard and excited the community is.
- Based in Patterns. There are patterns on varying scales, everything from MVC down to the Singleton pattern. Where there are larger, system wide patterns in use (like MVC) there are often a variety of other complimentary patterns and frameworks that fit nicely. Be sure that the frameworks you are choosing are based on sound computational science.
Cautions Worth Considering
- I have already mentioned the issues of complexity, code bloat, learning curve, and overreach, but here are a few other cautions worth considering when choosing frameworks.
- The implications of changing frameworks can be costly after the fact, and extremely so the larger and longer a framework is used. If doubts about a particular framework arise, there should be frequent review and serious consideration whether usage of that framework should be continued. The earlier the better, if it is going to be removed or swapped out.
- When it comes to learning new frameworks, it is extremely important to understand that learning curves aren’t merely additive, they are multiplicative. While learning and using a single new technology or platform can be straightforward, expecting to mix and match 3 or 4 brand new technologies starts to complicate beyond what can be reliably estimated. It is rare that a development team would expect to have no learning curve when starting a new project, but it is important to ensure that enough of the frameworks you are choosing are understood by enough of the development team. Each learning curve is adding risk to a project and too many unknowns can quickly lead to more risk than the potential benefits of using those frameworks.
- A long version history that boasts of backwards compatibility to v1, should be viewed as suspect since often the historical support implies all of the cautionary things that frameworks can introduce.
In conclusion, there is much to consider when choosing software frameworks, but the boost in development productivity and estimation accuracy makes them very worthy of the effort involved. As I mentioned in Things to Look For, the best frameworks are grown organically, where developers identify and extract reusable patterns. If your team is already doing this and then you have probably seen how much easier it is to estimate.
In the next post in this series I want to continue this direction of technical considerations while estimating and explore some of the considerations of the technical environment. I’ll discuss some of the issues that the development team themselves introduce in the estimation process.
