The logical assumption would be that more code coverage results in higher-quality code. But what Nagappan and his colleagues saw was that, contrary to what is taught in academia, higher code coverage was not the best measure of post-release failures in the field. Code coverage is not indicative of usage.
What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer.
The team observed a definite negative correlation: more assertions and code verifications means fewer bugs. Looking behind the straight statistical evidence, they also found a contextual variable: experience. Software engineers who were able to make productive use of assertions in their code base tended to be well-trained and experienced, a factor that contributed to the end results. These factors built an empirical body of knowledge that proved the utility of assertions.
Five Signs You Should Be a Low-Code Developer
If some or most of these traits resonate with your approach to work, then you’ve got what it takes to be a low-code developer. In this role, you’d understand that software development is about reaching the business goal and helping end users. You’d want to talk to users, understand their requirements and work closely with them in short, iterative cycles. Most of all, you’d advocate for the business value of IT and find great job satisfaction from making your customers and end users happy.Learning Curves (for different programming languages)
How to Ruin Your Company with One Bad Process
At this point, some readers may think that I’ve lost my mind. As a technologist, you know that the worst thing that you can do is over-constrain the problem before you start. You’ll kill creativity and prevent yourself from getting a truly great outcome. That’s precisely why I, as an engineer, struggled with this process: the human factors muck up the logic.Specifically, local incentives, if not properly managed, will sharply motivate human behavior and defeat the global goals.
It’s critical to recognize this so that you don’t turn your agile, small company into a slow, big company before its time
Technical debt 101
"A primer about technical debt, legacy code, big rewrites and ancient wisdom for non technical managers"
review of "97 things every software architect should know"
The book sure has its gems. Edward Garson provides an interesting piece on considering context that falls in this category. The gist of his writing is that architectural decisions are always made in a specific context. It's always a trade-off which may include conflicting priorities. Sometimes a certain context may force us to abandon even the most fundamental principles like simplicity.
In another chapter Keith Braithwaite declares the importance of quantifying non-functional requirements; neither "fast" nor "responsive" are real requirements. Rather we need to understand the desires behind a certain adjective like "fast". It's about asking the right questions and, from the answers, derive a quantitative criteria. Since I'm regularly exposed to new projects with these kinds of requirements, I think his advice needs frequent repetition.
Another favorite is Kevlin Henney's argument for use before reuse. Kevlin shows an alternative and, unfortunately, less traveled road to generality. By understanding known and specific examples, we can identify commonalities. These concrete examples let us move on to simplify and reduce the problem to a more general form. It's a case against speculative generality and well worth reading.
http://www.slate.com/blogs/quora/2012/05/24/what_makes_a_good_engineering_culture_.html
Good article on how a software design house should work...
- Optimize for iteration speed.
- Push relentlessly toward automation.
- Build the right software abstractions.
- Develop a focus on high code quality with code reviews.
- Maintain a respectful work environment.
- Build shared ownership of code.
- Invest in automated testing.
- Allot 20 percent time.
- Build a culture of learning and continuous improvement.
- Hire the best.
A lot of common sense here, but point 10 can be hard to implement..
<blockquote class="twitter-tweet" lang="en"><p>If isolation is good for services, then perhaps it's good for teams as well. <a href="http://t.co/cwP0DV3MCq">http://t.co/cwP0DV3MCq</a></p>— Jessica Kerr (@jessitron) <a href="https://twitter.com/jessitron/status/567332389136134144">February 16, 2015</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
How "agile" works at Microsoft. I'm impressed that they went as far as changing the office layout. http://t.co/W72Z9KYqWH
— Stephen Darlington (@sdarlington) August 6, 2014
Also has some good process links:
some free books for learning about software architecture http://t.co/MdTiODjLwf
— Anton Arhipov (@antonarhipov) April 24, 2014
IBM goes to Agile:
http://blogs.wsj.com/cio/2015/04/27/ibm-cio-designs-new-it-workflow-for-struggling-tech-giant/
How Agile Has Changed Test Management
How Agile Has Changed Test Management
- Share
- |
Read later
My Reading List
Agile methods have many traditional test management activities built into them. With desired agile team traits like self-organising, role blurring and skill diversification, the nature of test management is changing. We have to question whether the role of Test Manager should exist in effective agile organisations and how the activities which have long made up the role are divested?
According to Tom Roden and Ben Williams agile test management is about establishing the right culture of testing, educating people and getting hands-on in demonstrating how teams should go about making testing support agility. However, these are not traditional test management traits, which lends weight to the thesis that the role of test manager will cease to exist in agile organisations.
At the Agile Testing Day Netherlands 2015Roden and Williams talked about the changing face of test management. They showed how the role of test managers will transform into one that enables teams, rather than managing them. The resultant shift in approach and responsibilities will also mean that agile teams will pick up many traditional test management activities. which changes the role of the test manager significantly. Further more test strategies in agile should be treated as living documentation, that live, breathe and grow along with the teams and people who use them.
No comments:
Post a Comment