Software Development | The SoftFluent Blog

Save time for Windows 8 Store apps with CodeFluent Entities

October 18, 2012 Leave a comment

In the next few days, Windows 8 will be released bringing a set of new features.

Indeed, Windows 8 will come with a brand new user interface. This interface, which used to be known as “Metro” is already implemented on Windows Phone devices for more than two years, so you may be familiar with it.

This new user interface brings some changes in the Windows universe UI. For instance, the “Start menu” has disappeared and has been replaced by a “Start Screen” where you’ll find all your apps.

“Oh wait…apps? Do you mean that my computer has been turned into a smartphone? Will I still be able to use my current software with Windows 8?”

Don’t worry! Your good old desktop is still there and your current software will continue to work. Indeed, your computer hasn’t been turned into a smartphone but to answer customers’ current and future needs and expectations, Microsoft had to provide a user experience which fits with both computers and tablets (i.e. mouse/keyboard and touch screens).

Windows 8 Store apps can be downloaded from the “Windows Store” where you can find free and payable apps which, once purchased, are linked to your Windows Live account.

As disturbing as it is at the first look, this new Windows provides a lot of new possible uses for end-users and enterprises. The “Windows Store” is accessible in 120 countries. So people from 120 countries can now buy your apps! A lot of potential customers represent a lot of potential incomes thanks to this store and this income can be generated a lot of different ways (e.g. payable apps, advertising, and in-app purchase).

So far, I’ve been talking mainly about BtoC apps but you can also develop a Windows 8 Store app dedicated to your own business. For instance, you may have an existing SharePoint server hosting your extranet and you would want to offer to your co-workers more mobility. Windows 8 Store apps give you the ability to provide a new, friendly, itinerant, and interactive way to present your old data. Besides, you won’t have to go through the “Windows Store” to deploy a Windows 8 Store app, you can develop Windows Store apps for your enterprise only. You can add them to Windows devices you manage through a process called “sideloading”. “Sideloaded” apps don’t have to be certified by or installed through the Windows Store.

Contrary to BtoC apps, enterprise apps will depend heavily on business needs and as such susceptible to evolve continuously during their lifetime (even during development time!). Integrating new requirements or new technologies in such applications is usually difficult and risky, if you didn’t anticipate it properly. CodeFluent Entities was born 7 years ago from this ascertainment and has been designed from the grounds up for these kinds of scenarios. CodeFluent Entities is a Visual Studio integrated code generation product, based on a technology and platform independent model, and allows continuous code generation to more than 20 target platforms (databases, business layers, UIs, etc.)

CodeFluent Entities is already compatible with Visual Studio 2012 and a “Windows Store producer” (generator) has been shipped last month. This producer allows you to generate a complete Windows 8 Store application, its relational database and its JSON web services back-end. We’ve published an article which shows how to use this new producer a week ago.

Filed under CodeFluent Entities, News, Software Development Tagged with Application development, CodeFluent Entities, Development, HTML5, JavaScript, SoftFluent, Windows 8, Windows 8 app

Measuring software development performance – Part IV : Debt minimization

August 16, 2012 1 Comment

In our previous articles about software development team performance, we talked about alignment productivity, and quality.

Today, let us talk about debt minimization.

Debt minimization capability

IT debt is a notion that is getting more and more popular at the analyst level. Gartner estimates IT debt to grow as large as 1 trillion $ by 2015.

Up until recently, IT departments have presented the cost of developing applications without really explaining or measuring the induced cost for the future.

But as soon as you develop and deploy an application, you generate recurring maintenance costs that will last as long as the application is used. This cost will disappear only when this application is replaced.

Experience shows that applications always last longer than anticipated for several reasons. Even when you think of an application as a temporary solution, there will be business changes or budget restrictions that may impact the timing of the next version; there might be issues, as with all software projects, causing late delivery; or even, possibly, there may be technical disruptions that result in the failure of subsequent application launch.

So delivering an application that will run with the minimal maintenance effort is actually one of the most important elements to consider when measuring performance of a software development team.

About five years ago, in a software vendor meeting, Microsoft had shared this slide. It was the evolution of developer teams for the Windows group split by roles. The blue bar indicates developers dedicated to maintenance, the orange bar indicates the ones dedicated to compatibility and the yellow indicates the one focused on innovation. This illustrates the evolution challenge cost (especially for an ISV) when a piece of software is used and successful. A lot of your development bandwidth is necessary to maintain the legacy.

The Windows slide also illustrates a very important point. Application debt is usually tricky to measure because most of the associated hidden costs are not included the pure corrective maintenance cost. Of course, when an application is really buggy, people notice they have a big issue and usually take some actions.

But in most cases, a significant part of the real debt is hidden in a bad design that translates into over-sized evolution maintenance costs, the issue becoming bigger and bigger over time. The slide above does not really indicate if the innovation part produces as much value as it did in the past. However, one can get some insights thinking that the effort was mostly part of some pre-Vista work.

Issues are difficult to avoid, because people usually only realize there is a problem after it is too late. It is a bit like the “leaning tower of Pisa”. And the real solution in these cases is to rebuild, which organizations think they cannot afford.

So they will spend much more money in maintaining a badly-designed system but – because it is usually less visible than the tower of Pisa in software – this fact will be hidden in operating costs and associated with the cost of “unreasonable evolutions” asked by those “over-demanding business users”.

If your evolution costs look like the non-industrialized curve below, it is time to think about a real modernization of your application:

In our view, there are two different kinds of systems:

The ones which are very stable functionally. With these systems, even if an individual evolution might be too costly, it is probably good to maintain it for long as possible, even when the technology is very old. People often launch project when the technology is no longer supported by vendors. In our view, this is not a so important argument, when your system has run for decades. There is little risk that it stops with such a history behind.
The ones which are still alive because the business requires relatively quick adjustments to the application. With these systems, if you have run into a “heavy debt” situation, it is always better for the long term to re-design and solve the issue. The tricky thing is that you probably need to do this “by pieces”, to secure the success of the project; “big-bang” projects often lead to major failures. Throwing away old pieces of code, reducing the size of the code base and aligning it to more recent technology will save a lot of money rather quickly. But you need to do it the right way, with the proper approach, the right people and efficient tooling.

The leverage effect of application debt

As your application grows, the legacy you have developed weighs on maintenance, and over-complexity may severely impact the cost of evolution.

Let us take a typical scenario for an application that has a 10 year lifecycle. The following table describes a “nominal scenario”, with an initial development of 100 and evolutions over the following years. Maintenance is calculated as 15% of the cumulated past workload.

Nominal scenario

Cost line	Year 1	Year 2	Year 3	Year 4	Year 5	Year 6	Year 7	Year 8	Year 9	Year 10	Total
Initial Development	100										100
Evolution		30	15	50	25	10	40	25	16	5	216
Maintenance		15	20	22	29	33	35	41	44	47	284
Yearly cost	100	45	35	72	54	43	75	66	60	52	600

This scenario gives an overall cost of 6 times the initial cost, which is consistent with many projects that live normally and have certain levels of evolution over time to align with the business.

Now, let us imagine a team that is not fully optimal but adds a bit of extra complexity with a classical factor of 20% a year, which is not outrageous. Still, we estimate that the complexity multiplies over the year and increases the cost of evolutions by this cumulative approach. We still calculate maintenance by a 15% of the past workload.

Yearly over-complexity deviation factor: 20%

Cost line	Year 1	Year 2	Year 3	Year 4	Year 5	Year 6	Year 7	Year 8	Year 9	Year 10	Total
Complexity deviation	1,2	1,2	1,2	1,2	1,2	1,2	1,2	1,2	1,2	1,2
Initial Development	120	0	0	0	0	0	0	0	0	0	120
Evolution	0	43	26	104	62	30	143	107	83	31	629
Maintenance cost	0	18	24	28	44	53	58	79	95	108	508
	120	61	50	132	106	83	201	187	178	139	1257

The cumulated cost of the project is doubled in the end, and interestingly, the cost of the evolution in year 10 is 6 times what it would be without the burden of this overly complex legacy!

Another observation that might be of interest is to understand what happens when projects start the wrong way. With a starting complexity deviation factor of 30% at the beginning, even if you react and behave perfectly over the following years by progressively lowering the factor from 1,3 to 1, you will never decrease your yearly maintenance cost enough to align with the previous team.

Yearly over-complexity deviation factor: starting 30% but going down to zero

Cost line	Year 1	Year 2	Year 3	Year 4	Year 5	Year 6	Year 7	Year 8	Year 9	Year 10	Total
Complexity deviation	1,3	1,3	1,3	1,2	1,2	1,2	1,1	1,1	1	1
Initial Development	130	0	0	0	0	0	0	0	0	0	130
Evolution	0	51	33	132	79	38	167	115	73	23	711
Maintenance cost	0	20	27	32	52	64	69	94	112	123	592
	130	70	60	164	131	102	236	209	185	146	1433

Projects that start bad never end well, this is also a field observation that one can make. When it is really bad, it may be better to just start a new project. Here is a graphical version of the application cumulated costs of the three above scenarios.

Although a bit simplistic, we believe this model is consistent with some of our observations in the field where complexity translates into cost increases over time.

As we explained in the article about productivity, it is also very important to be able to estimate the real size and complexity of your project. A good estimation is also a way to ensure developing only the essential elements, because every single line of code that is not strictly necessary will be very costly over the whole application life cycle.

From our observations in the field, we are always surprised to find people are not familiar with simple metrics such as:

Number of business entities or tables,
Number of screens / pages,
Number of reports,
Number of lines of code.

For sure, one needs these factual elements (and even better, other details such as business rules, data properties, user interface fields, etc…) to be able to evaluate costs, both for producing software but also for maintaining it and implementing changes.

If the only criterion used to measure the impact of a feature request is workload, as defined by your developers, you may be in trouble. Firstly, you have no way of challenging this estimate, and second, there is a high degree of variability among developer skills.

As always, feel free to comment and share your own experiences.

Daniel COHEN-ZARDI
SoftFluent CEO

Filed under Software Development Tagged with Alignment, compatibility, debt minimization, it debt, legacy, maintenance, Productivity, quality, Software Development Performance

CodeFluent Entities supports Visual Studio 2012

August 14, 2012 Leave a comment

SoftFluent announces release of CodeFluent Entities for Visual Studio 2012 in August SoftFluent announces today that CodeFluent Entities and its Visual Studio integrated graphical editor will run within the final version of Visual Studio before August 31st 2012. CodeFluent Entities was updated to following the look & feel of Visual Studio 2012.

By leveraging CodeFluent Entities, developers can put the burden of keeping up with new technologies on the product, while focusing on developing the features they need for their applications.

Read the full Press Release

Filed under CodeFluent Entities, News, Software Development Tagged with .NET, CodeFluent Entities, Model-Driven, Visual Studio 2012

Measuring software development performance – Part III: Quality

August 2, 2012 2 Comments

In our previous articles about software development team performance, we talked about alignment and productivity.

Today, let us talk about quality.

Quality

Quality is a critical pillar of software development and measuring the performance of your team against this criterion is fundamental.

Quality consists of 5 dimensions: reliability, performance, scalability, supportability, and ergonomics/ease of use.

Quality is obviously a topic "per se", with its own best practices and organization challenges. We developed this topic in an article the "Software testing best practices". It became the most visited post on our blog.

So the idea today is not to address the entire broad topic of quality management; instead we will focus on how to measure the performance of your team based on the five dimensions of quality as it relates to software development.

Reliability

Measuring reliability of an application can be pretty straightforward, even if comparisons are not always easy because this information is most of the time kept confidential inside companies.

Basically the best indicator is the # of open bugs and their evolution over time. Of course, the less bugs the better. But be careful, a lack of bugs may indicate insufficient testing or that the application is not being used (except, of course, when you reach this state over the long term). And in general few bugs means that there are few evolutions.

What is really important to monitor over time when delivering software is:

· The trend for the # of bugs: it should increase at the time you deliver a new version of your software and decrease regularly from there; then,

· The split in importance of bugs: critical, major or minor,

· The consistency of the bug / line of code ratio when delivering new software.

An important indicator that we will talk about later on is the time needed to correct a bug. If a lot of time is needed to fix a significant number of bugs, it may be a sign of a bad design and those situations are likely to have an impact on reliability.

The consequence of a lack of reliability can be disastrous, especially for software publishers. Unreliability can dramatically increase the support cost of an application. There are some real stories of vendors that were killed or lost significant business by a lack of reliability of a specific version of their software.

Performance

We are all software users. Who of us has never grunted against a slow application or an unresponsive web site?

It is obvious when we are on the user side, but some developers tend to minimize the importance of implementing a responsive user interface. In the end, whatever the technical reason behind it or the work that is done by the software, users won’t use a solution that is too slow.

Consequently, when coding, you need to choose technical options that provide a good performance experience for your users. Of course, this does not mean doing anything only for the sake of performance, or everything would be written in assembly language, but it is important to always optimize the components that have a strong impact on performance: remote connections, data access, manipulation of the appropriate reduced set of data, usage of loops (especially imbricate loops).

If some data processing requires a lot of time, you need to think about asynchronous mechanisms, splitting data or using other design options to avoid a bad performance experience for your users.

The consequence of a lack of performance will be user non-acceptance of the application, whatever the proper implementation of features you provide. If it is an internal application, lack of performance may cause conflict in a company. If this is a product you sell… then you won’t sell it!

Scalability

People tend to confuse performance with scalability. These are two different aspects of quality, and sometimes they require contradictory design options.

Scalability is the ability for your application to grow without limit, either in the number of users it supports or in the volume of data it can manage. For example, Access is a very well performing DBMS, but it is not scalable; it doesn’t work well with many users.

With the emergence of the Internet, SaaS and cloud applications, scalability has become often more important than performance. And it is most of the time a technically challenging issue if you have to deal with large number of users sharing the same data.

With the diminishing cost of hardware, multiplying the numbers of machines is clearly less costly than over-optimizing performance with developer work time. But simply adding machines does not work; you need to design your application in a way you can split the work between those machines and still guarantee consistency.

Measuring the scalability of your applications is a rather costly process. It requires setting up complete bench platforms dedicated to the process of evaluating your application under a heavy load of users/data.

It also requires the appropriate tools and skills to correctly interpret the measures and be able to assess the elements you need depending on the growth of your user base. This process is known as "capacity planning".

A lack of scalability can cause a major business disruption. If the application becomes stuck, then it cannot welcome new users. And there is usually no short term solution if the application has not been designed with scalability in mind.

Supportability

Supportability is the ability of an application to be correctly operated in production.

One key element is the proper management of exceptions and errors, as mentioned in our article "Code instrumentation best practices".

A production-aware application should also be able to deal with non-forecasted events such as network failures, bandwidth drops or hardware issues.

To measure results on this dimension of quality, we recommend tracking the average time to correct a bug, which involves:

· finding what happened,

· finding the piece of code concerned,

· being able to get the data used in the scenario that caused the error,

· identifying the non-forecasted scenario,

· proposing a valid correction for the code.

The speed at which you can reproduce issues is also a key indicator for an application’s supportability.

Thinking about disaster recovery and how you can restore the application in case of major events is also part of this dimension.

The consequence of having an application low in supportability is the risk of downtime. Beyond the induced costs and the image problem, a discontinuity of service can impact business revenue when the system is down.

Ergonomics and ease of use

Ergonomics and ease of use is also a major pillar of quality.

Measuring this dimension and making comparisons is not so easy though. People tend to either underestimate the importance of ergonomics, or – on the other hand – expect every application to have the same ease of use as major consumer web sites, which are developed with tens of millions of dollars.

Some applications bear some intrinsic complexity of their business which might require very specific knowledge making it a specific a challenge to keep usage simple.

The best indicator of ergonomics is the ability to use and learn an application quickly. If possible, we recommend measuring this for new users. How much time does it require to get them on board using the application? If a long time is needed, how much is intrinsic to the complexity of the application and how much is related to the ergonomics and design?

It is better to measure this on new users than on users that might have been used to other systems. Their judgment may be biased by habit and some reluctance to change.

Increased ease of use will lower training costs, improve productivity of your users and ease the acceptance of the applications.

As with performance, a lack of ergonomics may result in user non-acceptance of the application and extra hidden costs.

In conclusion, when measuring the quality of your software development, don’t forget to assess all 5 dimensions. They all contribute to make your software successful.

As always, feel free to comment and share your own experiences.

Daniel COHEN-ZARDI
SoftFluent CEO

Filed under Software Development Tagged with Software Development Performance, Alignment, quality, reliability, performance, scalability, supportability, ergonomics, ease of use

Measuring software development performance – Part II: Productivity

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:

External Inquiries
External Interfaces
Internal Logical Files
External Outputs
External Inputs

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:

it requires a significant skill investment to really master the approach and get the expected results and measure,
it requires a quite rigorous and complete process in describing the software, an effort that we see less and less on the field as people have shifted to agile methodologies.

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:

number of entities
number of simple business rules
number of advanced business rules (cross-entity for example)
number of user interface elements (screens, web pages)
number of reports
number of external interfaces
number of batch calculations or processes
number of technology variations for components (rich-client, web page, mobile, database providers, cloud systems)

In projects using CodeFluent Entities, we often even found out that a project (including all project management dimensions) should never cost more than:

USD 5,000 per entity if it is an enterprise application,
USD 8,000 per entity if this is a packaged product that needs to be deployed at various customers (as it is generally more complex than a single-deployment application).

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

Filed under Software Development Tagged with Alignment, Developer Performance, Function points, Productivity, R&D Alignment, Software Business Alignment, Software Development Performance, Software Value, Velocity

Measuring software development performance – Part I: Alignment

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:

Alignment,
Productivity,
Quality,
Debt minimization capability,
Predictability.

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

Filed under News, Software Development Tagged with Software Development Performance;Developer Performance;Alignment;Software Business Alignment;Software Value;R&D Alignment

Code instrumentation best practices

June 4, 2012 4 Comments

Most developers overlook the production aspects of the software they develop. A program is always written to run somewhere into production – hopefully – and writing production-aware code requires some best practices supported by experience.

Without digging into advanced topics such as aspect weaving in aspect-oriented programming, we do think that there are basic dimensions of code instrumentation that should be known by all software developers.

Tracing

The first critical element of code instrumentation is tracing. Adding traces to your code is always a good idea. Yes, sometimes they might impact performances in some scenarios but this can be solved easily by adding different tracing levels, configurable at run time.

Too many developers still favor debugging instead of tracing making their investment disappear once they close their development tool. See our previous article "Our case against debugging". Properly done, tracing is much more powerful, as you should be able to leverage the trace information to understand and address issues into production. Most of the time, issues arise from unanticipated combinations of code paths or data values, so the developer should not make too many shortcuts or assumptions while developing.

Furthermore, over time, different developers will contribute to the application, not to mention to the same code file, but traces added to the code will remain, thus preserving the investment made initially.

Exception handling

Exception handling is the second important area of code instrumentation. When an exception occurs, you might be in unanticipated scenarios, or at least under specific conditions that require attention.

Dealing properly with exceptions, by taking relevant actions to maintain integrity, to provide information about data values or how we got there will prove to be critical to support the application in production.

In .NET, we still see a lot of issues around exception handling, like these ones::

The only result of this is losing the stack trace information, doing nothing would actually be better than catching the exception and reducing the available information. If you decide to manage an exception, make sure you can provide additional information or add value to the specific case.

Finally, if you want the full stack frame information available in production (with source file line numbers), it is also a good idea to deploy symbol files (.PDB), especially when deploying server-oriented application (Web)which is not always done.

Performance monitoring

In Windows, there is a very simple way to provide useful information related to performance at production time.

Performance counters are directly integrated in the operating system (it’s in fact there since the very first version of Windows NT), and you can create your own counters to monitor the relevant information with all the associated Windows tooling (Event Viewer). From the developer point of view, performance counters are also easy to define in .NET with all the associated classes.

From our experience, it is almost never used by application developers, as many tend to consider only the "out of the box" performance counters of the operating system or low-level components, losing an opportunity to measure performance in real scenarios.

Investing in those counters is a simple and pragmatic way of indentifying the key areas for performance improvement over the different releases of your application.

There are also tools that might help in profiling code "afterwards" but this is usually a heavier and more unpredictable process.

Data gathering and logging

Last but not least, for helping people supporting your application in production understand issues or optimize operations, it is often relevant to log some application-related data.

The developer of the application usually knows as he is coding what are the critical data elements that will be valuable when analyzing issues in production.

So don’t hesitate to log that data in a relevant place for your application, be it application log files or databases depending on the architecture and constraints.

In the end, ensuring these four dimensions are covered is not especially complex. It is more a matter of developer discipline than advanced expertise.

To read more

Commenting, Testing, and Instrumenting Code from Dr Dobbs
Instrumentation by Thomas Kyte
An Introduction To Performance Counters by Michael Groeger
Effective Code Instrumentation? discussion on Stack Overflow

Filed under Software Development Tagged with .NET, code instrumentation, debugging, exception handling, logging, operations, performance monitoring, production-aware programming, tracing

Interoperability and challenges in R&D (2/4)

May 8, 2012 1 Comment

The cultural component

Besides technical aspects, the cultural component is often a point you shouldn’t forget if you want your project requiring interoperability between different technologies to be successful.

Technical interoperability is like using a common language. It doesn’t rub the cultural differences.

With our clients, we have observed a lot of different contexts in the field, each bringing new difficulties to make completely different computing cultures to cooperate.

For example, some real life cases we worked on:

Huge mainframe system back-end integration with a Windows web server in the front,
SharePoint-based application using SAP processes,
Rich .NET client used to manipulate decisional data of a SAS repository on Unix,
iOS application using a full .NET back office and exposed through JSON/REST services.

Coming from different backgrounds, with different cultures and working styles, co-workers often feel hard to communicate, even just to implement the test process to validate the systems that need to interoperate.

In practice, it often takes a person to bridge the gap, someone who has already worked on both universe, or curious enough to get interested on a new set of technology and then acquiring skills to understand the big picture.

Global Benefits

There are plenty of benefits for software’s publishers in interoperability:

Benefit 1: Integrate into customer’s legacy

The first benefit of being interoperable for a software publisher is to allow integration into customer’s legacy environment.

In the IT, the inertia is really high and therefore the obsolescence curve is way longer than the forecast.

The existence of operational and validated systems, the importance of real production data and the habits acquired by users make any movement risky, and inevitably, economically costly in the short term.

So, one of the most important solution choice criteria is to ensure minimal disruption to systems that work.

Therefore, every solution which can integrate with the legacy, evolving step by step, has a major asset to be considered as compared to those who can’t.

Benefit 2: Enlarge your targeted market

The second benefit of interoperability, platform-wide, is to enlarge your targeted market by supporting a maximum of the platforms available as:

Databases,
Middlewares,
Operating systems,
Web browsers,
Mobile platforms,
Cloud platforms.

With a lot of investment, a software publisher can enlarge its target by diversifying platforms where its solutions works on, because many customers impose or favor one technical environment or the other.

Benefit 3: Optimize the value/cost ratio and invest in differentiation

The third interest in interoperating with other software suites is to focus your effort on the differentiation. Levering other software pieces that are doing great with some transversal or mature functions, we can invest our energy, time and money developing more accurate functionalities which will make our offering unique.

Depending on the sector and the application type, this kind of approach can be optimal in terms of generated value for a given cost.

It’s the principle of “best of breed” and effort concentration on the best element for a given sector.

Benefit 4: Comply with any regulatory requirements

Finally, you’ll have to remember that interoperability is often a regulatory requirement.

In a lot of businesses there is regulation to protect customer from being captive of a publisher who’s using too much proprietary formats.

Depending on the market situation, some legal work made sometime necessary to maintain the competition. Depending on the region, there are various laws to protect interoperability, from format regulations, to decompilation authorization, not to mention the very visible anti-trust actions that sometimes target the giant companies.

The lawmakers try to preserve a balance between intellectual property protection and the assurance of a competitive environment serving customers interest.

Filed under Software Development Tagged with Cloud, formats, fragmentation, Interoperability, platforms, standards

← Older posts

Newer posts →

The SoftFluent Blog

Save time for Windows 8 Store apps with CodeFluent Entities

Measuring software development performance – Part IV : Debt minimization

CodeFluent Entities supports Visual Studio 2012

Measuring software development performance – Part III: Quality

Measuring software development performance – Part II: Productivity

Measuring software development performance – Part I: Alignment

Code instrumentation best practices

Recent Posts

Blogroll

Web Sites

Top Posts

Archives

Categories

Pages

Meta

Follow “The SoftFluent Blog”

May 2013
M	T	W	T	F	S	S
« Apr
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31