Approaches, Styles, or Philosophies in Software Development

Contents

• Introduction
• Background
• Lightweight Software Development - Benefits & Challenges, Example
• Approaches, Styles, Or Philosophies
• Conclusion
• Resources
• Revision History

Introduction

My mother asked me the other day whether I know what KISS is. The mention of the Keep It Simple, Stupid principle reminded me of a presentation that I made at work about a year ago. The company I was at was struggling to deliver a quality product while keeping up with piling user demands (and customizations). The management team was at a loss as to how to motivate the development and quality assurance groups and how to measure the outcomes. This problem is complex, multifaceted, cultural, and not uncommon within the software development community. While the unified theory of software laws still eludes us, there are many different approaches, styles, and philosophies that the software development industry can work with to meet their goals.

Here I outline some of the current trends popularised in small to medium sized software companies.

This article is a collation of other people's work. Any misplaced or missing credit is not intentional. If you know of an omission, please let me know and I will correct it. For more details, refer to Resources.

Background

• The management of these two systems is often very different and requires varying technical skills and philosophy, hence requiring the development of project management.
• In whatever field, a successful project manager must be able to envision the entire project from start to finish and to have the ability to ensure that this vision is realized.
• Project objectives can be formulated as S.M.A.R.T.
  • Specific
  • Measurable
  • Achievable
  • Realistic
  • Time-bounded
• Nowadays all kinds of management are expressed in terms of projects. Using complex models for projects (or rather tasks) spanning a few weeks has been proven to cause unnecessary costs and low manoeuvrability in several cases. Instead, project management experts try to identify different lightweight models, such as Extreme Programming for software development and Scrum techniques.

Lightweight Software Development

Benefits

Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches.

Source: Benefits of Agile Development [^]

Challenges

While Iterative development approaches have their advantages, software architects are still faced with the challenge of creating a reliable foundation upon which to develop. Such a foundation often requires a fair amount of upfront analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality.

Agile Survey: Widespread Adoption, Emphasis on Productivity and Quality [^]


• "I know you believe you understood what you think I said, but I am not sure you realize what you heard is not what I meant." (Appears in Roger S. Pressman, Software Engineering (A practitioner's approach), 5^th edition, 2000, Mc Graw-Hill Education, ISBN 978-0071181822; however the quote is attributed to many sources, including Richard Nixon, Robert McCloskey, and Alan Greenspan. It may have originated several decades earlier in an anonymous academic joke.)
• Steve McConnell in Code Complete refers to design as a "wicked problem" - a problem whose requirements and limitations cannot be entirely known before completion.
• The approach can also be very expensive if iterations are not small enough to mitigate risk; akin to... "If you don't know what kind of house you want, let me build you one and see if you like it. If you don't, we'll tear it all down and start over."
• The top three problems that Microsoft developers agree they have are (Software Development at Microsoft Observed: It’s about people … working together [^] ):
  • Understanding the rationale behind a piece of code (66%)
  • Having to switch tasks often because of requests from teammates or managers (62%)
  • Being aware of changes to code elsewhere that impact their own code (61%).
• In what environments will Agile be most successful? (by Steve McConnell)[^]
  • Full-blown Agile seems to me[^] to be best suited for environments in which the budget is fixed on an annual basis, team sizes are fixed on an annual basis (because of the budget), and the project staff's mission is to deliver the most valuable business functionality that they can deliver in a year's time with a fixed team size. This mostly describes in-house, business systems dev organizations.
  • Full-blown agile (especially the flexible requirements part) is less-well suited to companies that sell software, because maintaining a lot of requirements flexibility runs counter to the goal of providing mid-term and long-term predictability. We've found that many organizations value predictability more than they value requirements flexibility. That is, they value the ability to make commitments to key customers or to the marketplace more than they value the ability to "respond to change."
  • For anything less than full-blown Agile, however, we find that many agile practices are well-suited to the vast majority of environments. Short development iterations are nearly always valuable, regardless of whether you define 5% of your requirements up front or 95% up front. Keeping the software close to a releasable level of quality at all times is virtually always valuable. Scrum as a management style and discipline seems to be very broadly applicable. Small, empowered teams are nearly always useful. I go into more detail on the detailed strengths and weaknesses of specific agile development practices in my executive presentation on The Legacy of Agile Development.

Example

• Crystal Clear [^] Crystal Clear can be applied to teams of up to 6 or 8 collocated developers working on systems that are not life-critical. The Crystal family of methodologies focus on efficiency and habitability as components of project safety.
  • Frequent delivery of usable code to users (required)
  • Reflective improvement (required)
  • Osmotic communication preferably by being co-located (required)
  • Personal safety
  • Focus
  • Easy access to expert users
  • Automated tests, configuration management, and frequent integration

Approaches, Styles, Or Philosophies

• Top-down and bottom-up [^]. Top-down and bottom-up are strategies of information processing and knowledge ordering, mostly involving software, but also other humanistic and scientific theories (see systemics). In practice, they can be seen as a style of thinking and teaching. In many cases top-down is used as a synonym of analysis or decomposition, and bottom-up of synthesis.
• Design by Contract (DBC) [^]The central idea of DBC is a metaphor on how elements of a software system collaborate with each other, on the basis of mutual obligations and benefits.
  • What does it expect?
  • What does it guarantee?
  • What does it maintain?
• Test Driven Development (TDD) [^] Test-Driven Development is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate the changes.
  • Requires test automation
  • "Keep It Simple, Stupid" (KISS [^]) principle
  • "You Ain't Gonna Need It" (YAGNI [^]) principle
  • "Fake it, till you make it" principle
  • Requires techniques, such as discussion and code reviews for example, to ensure not only that the correct features are implemented, but that the resulting code uses acceptable styles
• Model Driven Development (MDD) [^] Model-Driven Development refers to a range of development approaches that are based on the use of software modeling as a primary form of expression. Sometimes models are constructed to a certain level of detail, and then code is written by hand in a separate step. Sometimes complete models are built including executable actions.
• Feature Driven Development (FDD).[^] FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined.
  • Develop Overall Model
  • Build Feature List
  • Plan By Feature
  • Design By Feature
  • Build By Feature
  • Milestones
• User Experience Development (UX) [^] User experience is a term used to describe the overall experience and satisfaction a user has when using a product or system.
  • Reducing excessive features which miss the needs of the user
  • Improving the overall usability of the system
  • Expediting design and development through detailed and properly conceived guidelines
  • Incorporating business and marketing goals while catering to the user
• Cowboy coding [^] Cowboy coding is a software development methodology without an actual defined method – team members do whatever they feel is right. Typical cowboy coding will involve no initial definition of the purpose or scope of the project, no formal description of the project, and will often involve one programmer.
  • Well known and common-place. Developers need no training to quickly ramp up and be productive.
  • Facilitates rapid project completion.
  • Allows for quick solutions for small problems. Often a problem is small enough and well understood enough that documentation and planning are overkill. Typically when the job is going to take a day or two, and involve only a single developer.
  • Can allow a spike to see if a programming idea is valid before embarking on a larger project that depends on the idea. A spike is where you write a small proof of concept application to prove that a method is valid. These applications generally do not form part of a real finished application.
• Chaos Model
• Prototyping
• ... 

Conclusion

This article is incomplete. It is only skin deep. But I hope that it provides a glimpse at some of the ideas, terminology, and challenges in circulation in the software development industry. It is meant to tease you into areas that may not have caught your attention yet.

In the future, I would like to be able to catalog all approaches, styles, and philosophies of software development; and provide adequate example(s) or case study for each one of them - in a structured, user-friendly, centralized format. : )

Resources

• Project Management [^]
• Software Development Process [^]
• Software Development [^]
• Programming Paradigm [^]
• Methodology [^]
• Software Engineering Topics [^]
• Crystal Clear Applied: The Seven Properties of Running an Agile Project [^]
• Five Questions on Agile Development [^]
• Known Anti-patterns [^]

Revision History

• 2009-03-12 Added a conclusion
• 2009-03-08 Published on CodeProject
• 2007-11-01 Initial presentation