Back from holidays, back to work.
I’ve got some ideas for this new season, but let’s just start with a little ‘quiz’.
Imagine that you are asked to categorize an application acccording to its size, number of lines of code (LOC) or number of objects. What is your estimate of a small application? When do you say that an application is big? What are the numbers for a ‘monstrous’ one?
In our last post, we explained the concept of elasticity as the ability to move resources within a virtual infrastructure to answer business demands and (not always predictable) peaks with the best possible responsiveness.
Now, it’s not only about the ability to ‘inflate’ infrastructure by adding necessary resources, but also to ‘deflate’ it by reallocating these resources elsewhere. Like a balloon, the more elastic the infrastructure, the more it is easy to inflate and deflate.
What does that mean for your applications? Are they ready to go into the Cloud?
As we have seen in a previous post – Quality in the cloud – cost reduction remains the main motivation when it comes to go into the cloud and virtualized infrastructures. Then the second main reason is Capacity management.
When you have to size a physical infrastructure and a operating budget to manage it, the model is this one:
I must confess it: I have always been wary of the concept of technical debt. It has always seemed a marketing concept to me.
It’s like if you decided to buy a car, and the salesman will be giving you the keys and proudly adds with a smile: “you owe already $ 10 000”. And he does not speak about the car credit, no, he simply means that the car you have just bought contains certain flaws that will become increasingly apparent over time, and weary the engine, the body, even probably the driver.
How would you react if a salesman told you that? Would you buy this car?
I was invited last week to attend a marketing event where different customers did talk about their experience in the world of Cloud and virtualization.
It was really interesting: I learned a lot, but especially, I discovered the vision of the production teams about… application quality.
A message to the project teams: good times are running out. Continue reading
We saw in the previous post ‘Use cases – Working seamlessly together‘ what use cases are most often applied with a code analysis tool, and provide the greatest benefits:
We have seen in the previous two posts that some quite common use cases require just a limited number – 10 to 20 – of metrics. These use cases are:
A comment in the first post asked: “What are these 10 or 20 most important metrics?”
Continue reading
New Year’s greetings is always an opportunity to contact people and I did call someone I had not been talking for a while. As we are in the same consulting business, we soon were sharing views about how things were doing, and I asked him about a company where we have been working together.
He told me that their projects had been going so chaotic that they decided to outsource their applications. They recognized that they failed in maintaining the source code: too complex, too much difficulties to implement evolutions without generating a lot of defects, schedules not met, IT image and credibility going down.
My first thought was that they had made a great step ahead: they know that they do not know. Continue reading
Christmas soon, and every year the same concern: what gifts to offer? Ideally, the one that will please most and that will not ruin us.
I was on a forum trying to find information about an MP3 player when a post caught my attention: someone had a problem with a game console and asked if replacing the faulty component would extend the life of the console.
I was surprised: I did not know you could even replace a component on a console. If some component on your PC fails, you change the motherboard. And most often, you end up completely changing the machine if it is a bit old. Beyond 3 years of age, it becomes difficult to find spare parts, and in any case, it is often more attractive financially to buy a newer model. Continue reading
Following the previous post What is the first question ? about the two major questions concerning application quality – costs vs. risks – someone asked if there were some processes or best practices that contribute to these two objectives.
Is there a “best of both worlds” way to produce free defect software without exceeding budget and schedule? Continue reading