Think Six-Sigma Code is Not Possible? You just need to think like NASA

To get high quality code in your application, consider adopting NASA’s 10 rules for writing mission-critical source code:

1. Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion.
2. All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.
3. Do not use dynamic memory allocation after initialization.
4. No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.
5. The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements).
6. Data objects must be declared at the smallest possible level of scope.
7. The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.
8. The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code.
9. The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
10. All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.

According to NASA, the rules act like the seatbelt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable.

Read more here...

Another Potential Outcome of Pandemic Re-Engineering: Will Agile Adoption Grow?

A core aspect of agile is the idea that if a product or service does what customers need, they will be willing to pay for. At many organizations, an agile principle of customer collaboration is key. Products can be delivered quicker by working in iterations. In multi-disciplined teams professionals work together to deliver working software. This presentation talks about the financial returns generated via an agile approach.

It may take an expert in management consulting to translate into actual behavior and decision terms such as ‘waste’ (in Lean) or ‘flow’ (in Kanban), but the results can be impactful. But how do you know if work done by your teams result in value? What does ‘maximizing value’ mean in terms of behavior and decisions? What are the different kinds of value -- and are they equal? How do you compare them?

In these days of re-imagining the very foundations of conducting business, delivering a product or services, and other challenges brought about as a result of global pandemic, we could think of "business value" as an informal term that includes all forms of positive inputs that contribute to the health and well-being of an organization in the long run. The idea that agile can be used outside of software development is growing. Darrell K. Rigby, Sarah Elk, and Steve Berez of Bain:

“To create a truly agile enterprise,” in the May-June 2020 article, “The Agile C-Suite”, discuses, “the top officers—most, if not all, of the C-suite—must embrace agile principles too.”

Loyal readers of this venue recognize that agility, of course, is not a new idea. With members of the C-suite -- besides the CIO -- embracing the approach, will we see improved efficiency in other lines-of-business?

Read more at the HBR...

Agile Philosophies in Practice for Remote Workers

Have you made your move to your home office yet? Ensure you have a setup that works for you and your team. This may mean investing the time up front to evaluate options and put in place everything you need to be productive and comfortable. First, create a space where you are least likely to be distracted.

From an agile perspective, teams are most efficient when balancing time devoted to collaboration with time allocated to the concentrated efforts required for development and other knowledge work activities. When stationed remotely, workers have to be online — but also share their availability. Tools like Slack and Zoom allow you to communicate. Where possible, set availability status and mute notifications when you are embroiled in “flow.” Using status settings is important when teams are accessing flexible work hours.

Project managers, technical leads, and product owners should regularly enquire with questions about their teammates’ level of understanding around requirements, inhibitors to progress, and what might be needed to improve productivity. Some helpful tips include:

• Employ digital whiteboard tools for sprint planning and design sessions
• Schedule video web conferencing for stand-up meetings
• Assign one person to screen-share during reviews
• Craft simple surveys to capture feedback

Teams working remotely for extended durations may want to discuss documentation standards and see if more significant efforts would be helpful. Sometimes, documenting can replace in-person implementation discussions — the venerable wiki makes a great tool for this.

Leverage the philosophy of being agile, not just by following agile practices, but in recognizing how to embrace change, for the better.

How to Make Continuous Delivery a Reality in an Agile Environment

Continuous integration and continuous delivery (CI/CD) are core elements of successful DevOps. Systems engineers may start with CI because it is familiar. With a DevOps focus, organizations uncover configuration, packaging, and orchestration that are necessary to effective software development life cycle (SDLC). This empowers developers, administrators and engineers to create valuable CD practices, adding to agility.

Where less experienced developers might struggle with CI/CD performance, testing delays and other bottlenecks, the enterprise would do well to develop processes and best practices to make DevOps in the cloud a value-driven methodology. To save money, this will shorten the SDLC — because CD is all about updating web services. In public clouds such as AWS and Azure, this is done through pipeline stages (e.g. dev, test, staging and production). When containers are implemented with a platform-as-a-service (PAAS) approach, stages become sandbox environments, scratch instances, and production instances.

The benefit of such an approach is that the work outputs and products themselves benefit from flexibility. Regular face-to-face interactions and collaborations between team members are conducted to ensure the scrum teams level-set expectations. Finally, add value by continuous delivery throughout the life cycle, so that the end product is more secure and more reliable. Implementing an agile manifesto tracks with addressing evolving end user requirements. 

For CD, ensure user stories are married correctly to those requirements and that each story rolls up to an Epic that represents a standalone feature. This enables the devops team to release reasonably sized components of functionality that are consumable by users. These are also traceable back to the release plan. We want to ensure verification at each stage because this process defines acceptance criteria — so the stakeholders know when something is declared “finished.”

Schema, user interface, access control rights and static resources such as icons and images are all part of the creation process and we manage them just as diligently as source code. The DevOps team checks assets into a version control system as a single source of truth (GIT or Subversion). This benefits the client by ensuring that developers are making changes in a segregated environment — catastrophic failures are completely avoided with such approach, and integration into a risk management-based security framework is seamless. 

The organization should understand automated quality processes are essential — Selenium is a go-to tool for testing functionality. There are several verifications to make before functional testing. Static code analysis tools, such as PMD, are essential to ensure code conforms to a single style. Unit test coverage is also essential — establish a set of Key Performance Inidcators (KPIs) for coverage of at least 75% of code. Finally, after these automated tests pass, implement a manual peer review. This enables seasoned developers  to spot opportunities for performance improvement where automated tools can’t.

Project Management Tools - Analog and Digital - Have a Place in Agile

The value of cloud-based task and project management software is obvious -- link teams, keep all information in one place, automate workflow and progress monitoring.

With a good interface, an online tool enables teams to manage Agile projects to plan, assign, prioritize and track tasks efficiently. Use drag 'n drop kanban and backlog/sprint planners for easy and smooth overviews and assignments of tasks.

In the case of scrum, we find there will be multiple sprints. Teams needs to plan quickly for each daily standup. Does this preclude upfront identification of milestones with a WBS? Marrying the two styles is not as incompatible as one might think.  One can use an issue tracker as a to-do list that is focused on accountability. Such issues are the building blocks for progress and can be classified as tasks, bugs, or change requests. Being able to plan out milestones on Gantt charts might seem a strange crossover when applying Agile project management techniques such as Scrum or Kanban. But a timeline-based view of tasks and sub-tasks can aid in communication.

When a project management tool is highly integrated with Git, Subversion, or other code repositories, an integrated workflow is possible. We have found using a wiki to document projects is handy for its simplicity of use.

Read more here...

Why Process is Important to Scale Agile

Using SafeAgile and other lean software development approaches require customization for the organization. It isn’t good enough to just duplicate the efforts of others. Organizational change management means addressing top-down control that is in opposition to change — this will undermine agility.

Each agile team is different and needs to learn what works. In many cases, this means scaling agility outside of functional areas. Breaking down silos is key to the cross-over benefits of agile, reflecting the cross-functional nature of agile. Agility means putting in place defined engineering practices, with process controls.

While daily stand-ups and Kanban boards are important, to build high-quality software quickly, organizations should incorporate automated builds, automated testing, and automated deployments, among other things.

Read more... about SafeAgile

A New Year, Time to Take the Temperature of... DevOps

Sometimes adoption of DevOps results in chaos -- perhaps because of the evolving relationship between development and operations? When taking a shared approach to accountability for application life cycle, many still lack processes, tools, and monitoring needed to know who is ultimately responsible for addressing and fixing issues.

As the lines between development and operations continue to blur, perhaps one should focus on adopting tools that deepen visibility into applications?  It seems that clarifying ownership of applications and services avoids the "since everyone owns this, nobody does" model.

Read more about the state of DevOps

This offers a visual depiction of the various software development methodologies.

The only thing more difficult than building software for a client, is explaining how software is built to a client.

Tired of Scrum? Get Ready for the "Open Development" Methodology

While Scrum and other agile methodologies have made inroads since 1990s, much has changed. Startups and enterprises with workforces spread across time zones can no longer co-locate their employees as they were once expected to be able to. As the world shrinks, organizations are finding themselves in a position to decouple the software development approach from traditional means. We see open source everywhere in 2015 -- with the diversity of teams developing for the most popular open source projects, one wonders how to succeed without the benefit of managers, meetings, and code sprints?

With "open development," decisions are made in public view, and Project Managers and engineers are responsible for their own actions -- autonomous but accountable. The approach emphasizes more than just code delivery, but collaboration and transparency. The other aspect of open development method is in keeping the peer review process business-like and professional.

Another consideration is the role of software patents, an issue that remains controversial in the software industry. There has also been much discussion in the software development community over the increasing use of Web 2.0-style software services, otherwise known as Software as a Service (SaaS) or the ‘Service Cloud’.

As part of an open development method, code quality is paramount, so code should be legible, able to be tested, module and minimally verbose. Each of these factors benefits not only the development team, but stakeholders (and, ultimately, end users). Here's a quick summary of the open development philosophy.

How Project Managers May Facilitate Software Developers

Over at Frederico Tomassetti's blog, he discusses how PMs and developers should communicate business priorities and consider technical priorities as part of the process of improving how these two professions interact, with the goal of improving a work product.

As a student of the Toyota Method, I've often looked to industrial process improvement for ideas on how to better manage teams, specifically around technology projects. But software development is not about 'manufacturing' an application. Modern management comes from the industrial revolution, and the idea of increasing production by adding labor, machines, etc. Software, to me, is still very much an artisan craft. Understanding user requirements to be functional is key -- the more detailed the requirements, the more time developers spend figuring out how to implement. Beyond this, some problems require the abstract thinking of a software engineer or architect, not just the assembly of blocks of code.

I have found that unrealistic schedules are the major cause of project failure. In the 1980s, Frederick Brooks noted in “The Mythical Manmonth” that adding staff to a project that was behind schedule only helped it to be further behind schedule. When estimating a technology project, two key components are difficult to assess: the complexity of requirements; and, the productivity levels (outputs) of the development team.

My solution is to track progress, and that means capturing data (metrics). But if information is not collected or collected so inconsistently, comparisons and trends are impossible. If no data is being collected, management has not required it. If collected inconsistently, KPIs have not been established and enforced, or standards are burdensome so they are circumvented. Productivity measurement and project management are powerful tools for planning, overseeing, and evaluating software development and maintenance projects -- the PM should guide the ship, so developers can pull the oars together.

Read more here...

Ask Your Developer: Is this a Web or Cloud App?

When a customer asks, should we go Cloud vs Web, my response is frequently, what's the difference? Then, I try to illuminate with the following. These days cloud applications are all the rage… but what’s the difference between a cloud app and a web app, if they both run in your browser? And are mobile apps cloud-only? Confused? Don’t be. Here’s a quick primer on the differences (and similarities).

Let’s start with web applications — software accessed over a network such as the internet or an intranet via a web browser such as Safari or Chrome. Such tools are built with= a browser-based language (e.g. JavaScript), displayed with HTML and accessed with a common web browser. In web apps, the software as well as the database resides on a central server. This saves software developers from building and maintaining multiple client versions for a specific operating systems.

Cloud apps are hosted by cloud providers (Amazon, Google, others) and are accessed over the Internet. The software-as-a-service (SaaS) provider owns the software while the customers “rent the app” in a pay per use model. As web apps, they are used through a web browser so nothing needs to be installed locally. Cloud apps are generally architected to support multi-tenancy — enabling multiple customers (tenants) to be aggregated into the same application). Pricing is based on actual usage or per-user.

They seem similar, don’t they? Both types of apps are stored on a server and delivered through a browser interface over the internet. Cloud apps should have high availability (through mirrored installations in multiple locations) as a feature, while many web apps are limited in ability to support a fixed number of users. Cloud apps may offer extra security and integration with other systems via web services. Administrators of cloud apps can easily configure workload and traffic patterns in order to utilize the exact amount of infrastructure offered. Web applications are usually developed for a given platform, limiting scalability.

Mobile apps that access the same back-end over the internet would be considered cloud apps if the architecture and supporting infrastructure are cloud-based.

Developers Like Agile. Users Hate It.

Read at SlashDot: "What developers see as iterative and flexible, users see as disorganized and never-ending. '... She's been frustrated by her Agile experiences — and so have her clients. "There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed.

Too many people are involved, and, again, I repeat, there is no process.' The premise here is not that Agile sucks — quite to the contrary — but that developers have to understand how Agile processes can make users anxious, and learn to respond to those fears.

The more traditional approach is not fool-proof: 'Detailed designs and planning done prior to a project seems to provide a "safety net" to business sponsors, says Semeniuk. "By providing a Big Design Up Front you are pacifying this request by giving them a best guess based on what you know at that time — which is at best partial or incorrect in the first place."

The danger, he cautions, is when Big Design becomes Big Commitment — as sometimes business sponsors see this plan as something that needs to be tracked against. "The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.

Most important take-away:

Most non-computer businesspeople are already intimidated by spending money on something they don't understand. They have to report to someone who wants an answer to, "When will this be ready, and what budget do we need to allocate? And incidentally, if it's late, it's your job on the line."

Read Esther Schindler's article at ITWorld.

Agile Failure - UK's biggest software project not close to release. Ever.

Universal Credit is the world’s biggest ever “agile development” software project and a massive financial and social (and hence political) risk for the government. Unless delivered on time and on budget then the consequences are grave – some of the most vulnerable people in society could be left literally destitute, with all that entails for their personal welfare and social order.

Yesterday the U.K. finally admitted in public what the rest of us have known for a long time: that the project is in deep trouble. The report placed UC in the “red-amber” category – not yet failing but very close it. The back end – the benefits calculation – has reportedly been shifted to a “waterfall” development process – which offers some assurances that the government at least takes its fiduciary duties seriously as it should mean no code will be deployed that has not been finished. The front end – the bit used by humans – is still meant to be “agile.”


Read more here...