.NET Software Engineering best practices
July 19, 2012 1 Comment
Mykola Dobrochynskyy, an experienced senior software engineer has written an article in German for Dotnetpro Magazine. It has made the front page of the magazine.
If your native language is German and you do not know yet about CodeFluent Entities software factory, this is a good place to start, just buy this Dotnetpro edition.
July 13, 2012 4 Comments
In our last article about software development team performance, we developed the alignment pillar.
Today, let us talk about productivity.
Productivity
Productivity is obviously a critical performance indicator in every business. But as software developers are costly and scarce resources, it is all the more important in that area.
Still, and although developing software is not really a new discipline, there is no universally recognized methodology to measure software development team productivity. The first thing to ask is: "Why is it so?"
First, by definition, each piece of software built is unique. You don’t need to build two times the exact same piece of software as you can reproduce it indefinitely by copying it. This makes it really impossible to make a formal and rigorous comparison between two pieces of software.
Second, the up-to-date technology is something that changes at a quite rapid pace. So each time a methodology relative to a certain wave of technology is reliable enough, it is generally already obsolete.
Third, there is a huge area for creativity in finding the different solutions to a unique problem. So measuring the result in terms of "lines of code", for example, is measuring the size of the solution, not the problem. And among the solutions to a problem, the lightest solution is actually the most valuable one, not only because it might cost less to produce (sometimes not by the way, it can take longer to write a synthetic text than a long one), but mostly because it costs less to maintain.
This said, should we give up with the idea of measuring software development productivity?
This is not our opinion at SoftFluent.
Let us start by looking at different industry approaches to address the topic.
Agile methodologies
Undoubtedly, this is the major methodology trend at the moment in software development. Still, the focus of agile methodologies is mostly about securing an efficient collaborative process between product management and developers. It addresses pretty well the alignment challenge we talked about in our previous post.
Talking about productivity, the standard practice is to evaluate development task using complexity levels and "points". Depending on the level of complexity, a non-linear formula gives the development time.
In many agile methodologies, the evaluation uses Fibonacci series to find development time depending on complexity. Fibonacci series is built in a way each number of the series is the sum of the two previous numbers, which gives us this kind of table.
| Complexity level | Estimated development time ratio |
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 5 |
| 5 | 8 |
| 6 | 13 |
| 7 | 21 |
| 8 | 34 |
When managing the backlog of features, these are evaluated in complexity which translates into points. The classical measure used in agile methodologies then focuses on velocity which is the number of points developed per iteration, as per the schema below.
This works pretty well to evaluate the relative efficiency of a given team over time. But the main weakness is that it only gives a relative measure. Points are defined by the development team and cannot be compared to anyone else on the market. So there is no way to benchmark your development team using this approach only.
Function points analysis
Function points analysis is an evaluation method that addresses this challenge by defining in an "absolute" way what needs to be produced in terms of complexity.
Using categories such as:
One needs to describe in a detailed way the different functionality of the software in each area.
There are then complexity matrixes where one can position the different functionality and calculate the adjusted function points of their project.
For people who want to know more, we recommend this document from Software Metrics, a company specialized in that area.
Working with traditional waterfall methodologies with a significant design phase can work pretty well and should be comparable from project to project.
The main drawbacks of this method are the following:
Our own approach for business software
In our view, we think that getting some absolute measure of the software that is produced by your team for a given budget is really important.
And as we understand the challenges mentioned above, we adjust our own simplified methodology to measure the size of a software development project, specializing in the area of "business applications".
When we talk of business applications, we consider all kind of applications that usually manipulate structured data, internal applications focused on a specific business or vertical, customer-relationship management software, complex e-commerce or Extranet web sites, and etc.
In our experience, the size and complexity of a project is a function of a quite limited number of parameters, that compares from a project to another, whatever the sector or domain area.
Each application usually has a bit of specificity in some way (workflow complexity, external connection challenges, dynamic user interfaces, customized advanced business calculations or multi-tenancy for SaaS applications), but we observed that the impact it has in terms of development cost is relatively constant from a project to another.
If you combine several complexity factors, you may also find ratios that help you deal with this complexity and you should be able to evaluate a project based on the following numbers:
In projects using CodeFluent Entities, we often even found out that a project (including all project management dimensions) should never cost more than:
This gives a very simple way to detect issues when auditing real-world projects with a bit of history and legacy. We also compare this information with the total number of lines of code for the application. Our experience gives us relatively constant ratios correlating the number of entities to the numbers of lines of code in languages such as C# or VB.NET.
We also found out that CodeFluent Entities reduces the number of manually written lines of code by a factor of 2, with a direct link to the future maintenance effort.
And of course, the good news when using our tool, is that you get at least metrics about all the parameters mentioned above, whereas we still see many "blind" customers on the field, that are unable to know these key metrics.
What about your own experience?
We are eager to hear from your experiences, as this is a very hot topic.
Daniel COHEN-ZARDI
SoftFluent CEO
July 6, 2012 6 Comments
This question is a tricky one. If it is pretty easy to measure the performance of an enterprise, or compare performance of sales or financial departments using business-oriented ratios, the exercise of measuring the performance of development teams seems to be a very hard topic.
Especially when these teams need to create commercial products and innovate, for example in the case of software publishers, a universal measure seems almost impossible to determine.
In particular, it is pretty easy to measure costs, but how can one measure the real value of what is produced? The real value is mostly what will be transformed through sales, and it does not solely depend on the R&D team. Furthermore, there might also be some additional value opportunity in the way it helps the users make strategic decisions by providing relevant information and presenting it in a smart way. So measuring the intrinsic performance of the technical team is not easy.
For enterprise applications, it might seem easier as the value mainly lies in the support of business processes. But digging deeper in to the topic, it appears quickly that the understanding, management and evolution of these processes is a responsibility that spans departments beyond the technical team.
How the development team contributes to improve the way a company manages his business is the key to high performance. And this requires a real collaboration between the software development team and other departments.
In our view, there are five pillars of software development team performance:
Those five dimensions are important for having a successful software development team and perform over the long term.
Alignment
Let us start by alignment. It is probably the most important factor for performance as it has a huge leverage effect, and can create significant differentiation between teams.
Many people only measure productivity (or even worse, just cost) but this does not make sense if nobody really checks how aligned to the business value the development effort really is.
On the following schema, software team #3 produces less than the others (shorter arrow) in terms of quantity. Still, this team will provide more value to its company as its efforts are more aligned with business needs (the projection on the value axis).
And as maintenance cost are strongly related to the amount of code produced, the benefit of a great focus on relevant value will even increase over time, whereas teams 1 and 2 will maintain more non-valuable pieces of code and bear a heavier application debt.
Of course, the obvious issue is that this alignment is hard to measure. How can one really detect the non-productive effort on a project?
Still, our experience of auditing applications and software products demonstrate that development teams often over-invest in technical frameworks and approaches that are way too costly when compared to the value it provides for the business of the company. We often detect non-used code, functions that already exist in standard classes and over-engineering techniques that does not provide any real value in the context of the application.
This syndrome happens because technical people love technology. Then they try to solve issues they don’t even have or apply things they read over the net without really understanding whether it applies to them or not.
Another issue when dealing with alignment is the positioning of the technical team in certain organizations. Sometimes, the technical team is positioned only as a technical resource that has no added-value beyond producing what is decided by the sales or marketing department, without having a word about potential design options.
Once in this situation, you get of course a weak technical team, which then justifies the full lead by the business people. Organizations are then trapped in this vicious circle and are doomed to get no real input from smart engineers that could propose the best design options to optimize the value/cost throughput ratio.
Of course, there are low-value applications with few areas for creativity and only room for detailed work provided by a business expert. But those applications are very likely to be available on the market as packaged software, so why would you develop them in that case?
Teams that went down that road often off-shored their developments to low-cost countries, and most of the time, they lost their ability to induce a major evolution of their offering. And guess what, at some stage, they are often caught back by some major functional disruption on their market, not to mention the permanent need to follow up technology innovation, a challenge all software teams faces.
In our experience, it is only with the contribution of software engineers that you can make a real long-term difference on the market, as those guys are the ones able to make some critical choices that will impact the software development cost with another order of magnitude… for the same value!
In our view, only a smooth and durable collaborative process between people who master technology and those who master the advanced needs of a market can produce new innovative solutions that will succeed on the market. This is the primary reason why agile methodologies are getting so popular. They mostly favor implementation and durability of this collaborative process.
Beyond ensuring this alignment as part of the methodology, there are also ways to evaluate your current level of alignment using external auditing for example. It can help you discover areas of code that could be simplified and refocused on your business.
Another advanced way of maintaining this alignment over the long-run is putting usage data directly into the application. This is especially interesting for SaaS applications as the software publisher can then easily track features that are actually used by their customers. Monitoring usage provides critical information for knowing the value of each feature and choosing the proper areas of investment, based on facts, and not only on customer perception.
Daniel COHEN-ZARDI
SoftFluent CEO
