Long working days, deadlines and team pressure can impact the quality of the software that agile teams deliver. What can we do to prevent that from happening and enable teams to improve the quality of their software? Some suggestions are to arrange for scope and deadline slack, adopt pull systems, and to make sure that people can slow down and get enough sleep.
Delivering faster is one of the reasons that enterprises mention why want to use agile for software development. How can agile be used to become faster?
In its recent issue the Chip Design Magazine points out that the huge growth of portable and wireless systems combined with the increasing relevance of software in embedded systems poses a challenge. Quality issues need special attention, especially in safety-critical systems. This is why software test tools for software systems will become increasingly important.
In two recent papers, David Chappell, Principal of Chappell & Associates, outlines the different aspects of software quality – functional, structural, and process-, the groups of people directly interested in quality –users, developers, and sponsors-, and the outcome of defects in externally or internally facing software over time.
Tony Wong, a project management blackbelt, enumerates some practical points on individual procutivity. This article wonders how well these apply to software development and contrasts his list with that of other lists.
On the 1st November software engineer and author John R. Fox has published his book “Digital Work in an Analog World”. According to its subtitle “Improving Software Engineering by Applied Psychology”, the book does not consider software engineering in practice. Rather, it is focusing on the psychological aspects relevant and practices relevant for engineers.
Facebook is probably the hottest company today, driving a very high level of interest and scrutiny. Despite a high level of secrecy, Yee Lee, a product manager at Skype, has assembled a large collection of notes detailing how code ships at Facebook.
What can you do when unacceptable numbers of stories are "done" with development, but they still have many quality problems?
Technical debt can be difficult to connect directly to customer value, but delivering customer value is what Agile processes are all about. So how can we track and reduce technical debt in an Agile development environment?
Big Ball of Mud, is a code jungle which is haphazardly structured, sprawling, sloppy and connected by duct-tape. Over the years we have been introduced to various guidelines such as SOLID, GRASP and KISS amongst age old, high cohesion and low coupling to deal with this Mud. However, the situation still remains bleak and Big Ball of Mud seems to be a popular way to design and architect software.
W3C has released Unicorn, a one-stop tool to help people improve the quality of their Web pages. Unicorn combines four popular tools, including the Markup validator, CSS validator, mobileOk checker, and Feed validator, with a single interface.
Gerald Ford International Airport has a parking lot fee calculator and Matt Heusser noticed that it was buggy. So he issued a challenge to testers around the world: Find the bugs in ParcCalc. The respondents included James Bach, Selena Delesie and many others.
Most Agile teams recognize the evils associated with technical debt. Just like a financial debt, the technical debt incurs interest payments. These are paid in the form of extra effort required to maintain and enhance the software. Most Agilists recommend repaying the technical debt as early as possible. However, most Agile teams fail to monetize the technical debt.
There is code which is well tested, well re-factored and built to last. There is also code which is planned to be thrown away in a few days. Between these two extremes, there is a lot of gray area. The code in this gray area is written with the presumption that it would be cleaned up later but is never done.
Any developer has written at least one line of comment throughout his code. Some have written many comments in an attempt their code to be more explanatory. This article gathers some of the practices used in writing code comments.