News Stay informed about the latest enterprise technology news and product updates.

Microsoft to Yahoo: No more Mr. Nice Guy

Microsoft CEO Steve Ballmer has given Yahoo’s board three weeks to accept Microsoft’s $31 per share buyout offer. If Yahoo still does not move, he said Microsoft will put the offer in front of Yahoo shareholders and initiate a proxy fight. He also intimated that Microsoft might revise its $40 billion bid. Downward.

Money quote from Ballmer’s letter dated April 5:

“The substantial premium reflected in our initial proposal anticipated a friendly transaction with you. If we are forced to take an offer directly to your shareholders, that action will have an undesirable impact on the value of your company from our perspective which will be reflected in the terms of our proposal.”

Barbara Darrow can be reached at bdarrow@techtarget.com.

Join the conversation

3 comments

Send me notifications when other members comment.

Please create a username to comment.

From my point of view Software Automation is a requirement and definitely it adds to savings for the organization.
If you look around in any industry the Automation has taken up a significant role starting from power looms to the Automobile assembly lines and latest being self-replicating 3D printers which is a future trend for AI + Automation.
And that kind of Automation will be the case with Software industry as well. The main difference in the Industrial Automation and Software Automation is that Industrial Automation is more towards “Production” whereas Software Automation is more towards “Development”.
Actually the problem arises when management starts looking at the Automation as a replacement for Testing/Validation and start replacing Testers with Automation Framework + Scripts, which is not the right way to look at it. Validation is a process to ensure the quality(which I would say include the design, usage & conformance aspect as well) of the product being developed and automation is just an enable to support some part of validation so Automation is not a replacement for Validation but an enabler. And Automation is just a shadow of Validation i.e. it just mimics what Validation would be doing so the effectiveness of Automation is completely based on what the effectiveness of the Validation Strategy is. So you can have a very good Automation framework to support you but if your Automation Strategy is based on “weak validation strategy” then no “great Automation framework/tool” can help you achieve quality.
And it’s been rightly pointed out that the most important entity in ensuring quality is the tester and Automation is a tool available for him/her to get few of his tasks done to achieve his/her objectives.
Now talking about “savings” again is a bit subjective so first let me ask a question… has “Automation of transportation” i.e. Automobiles helped us save cost in achieving objectives (e.g. movement of goods before it gets spoilt, movement of people to certain location to get some work done etc.)? The answer is definitely “yes” but currently do we calculate that cost… the answer is definitely “not”, but that doesn’t mean that it has not helped. So we need to start looking at Automation as any other tool which helps us achieve our overall objective.
Cancel
From my point of view Software Automation is a requirement and definitely it adds to savings for the organization.
If you look around in any industry the Automation has taken up a significant role starting from power looms to the Automobile assembly lines and latest being self-replicating 3D printers which is a future trend for Artificial Intelligence + Automation.
And that kind of Automation will be the case with Software industry as well. The main difference in the Industrial Automation and Software Automation is that Industrial Automation is more towards Production whereas Software Automation is more towards Development.
Actually the problem arises when management starts looking at the Automation as a replacement for Testing & Validation and start replacing Testers with Automation Framework + Scripts, which is not the right way to look at it. Validation is a process to ensure the quality (which I would say include the design, usage & conformance aspect as well) of the product being developed and automation is just an enable to support some part of validation so Automation is not a replacement for Validation but an enabler. And Automation is just a shadow of Validation i.e. it just mimics what Validation would be doing so the effectiveness of Automation is completely based on what the effectiveness of the Validation Strategy is. So you can have a very good Automation framework to support you but if your Automation Strategy is based on weak validation strategy then no great Automation framework/tool can help you achieve quality.
And it’s been rightly pointed out that the most important entity in ensuring quality is the tester and Automation is a tool available for him/her to get few of his tasks done to achieve his/her objectives.
Now talking about savings, again is a bit subjective so first let me ask a question… has Automation of transportation i.e. Automobiles helped us save cost in achieving objectives (e.g. movement of goods before it gets spoilt, movement of people to certain location to get some work done etc.)? The answer is definitely yes but currently do we calculate that cost… the answer is definitely not, but that does not mean that it has not helped. So we need to start looking at Automation as any other tool which helps us achieve our overall objective.
Cancel
I completely agree, and would make the point that creating better testers and quality-minded engineers is MORE important than your automation effort. In our Agile working structures it is necessary to have both in place in order to realize the power of fast and nimble development. We need scripted tests that can run with every build process, along with integration and regression tests that continually give us confidence in the stability of our code.

In addition we need well trained engineers who can investigate requirements, explore complex data relationships, understand the customer needs and use of the product, create a testable architecture, and constantly groom and improve the testing cycles to keep them current and efficient.

So many lessons of Quality Assurance principles have gone out the window in the last decade because teams are pursuing the magic bullet in agile and test automation. I still see agile teams that put off the testing until “the next sprint”, or pile all of the testing on the shoulders of a few QA Engineers, hopeing they do enough coverage. The core quality principles, while changing, remain an integral part of developing a complete quality lifecycle. Perhaps the most obvious one is the idea of continuous improvement. The agile teams that practice retrospectives and are always improving are in the minority today, and even then most focus on improving other areas and not quality.

I recommend two key areas to focus on;

1. Train your QA staff more effectively in automation and Quality Assurance principles. Build a more capable testing staff. Augment with outside help, but it is important to grow your talent internally.

2. Have each agile team commit to one single quality improvement with each retrospective. The incremental improvement over time will transform your practice and lead to higher quality and productivity.

Finally, as a Quality Leader you need to be an advocate for these things and help the agile teams and the executive management understand and see the value in building quality into your everyday practice.
Cancel

-ADS BY GOOGLE

MicroscopeUK

SearchSecurity

SearchStorage

SearchNetworking

SearchCloudComputing

SearchDataManagement

SearchBusinessAnalytics

Close