DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Software Development is Upside Down

Software Development is Upside Down

The author observes a handful of common management maxims and suggests that they need to be reversed for effective management to happen.

Allan Kelly user avatar by
Allan Kelly
CORE ·
Aug. 08, 16 · Opinion
Like (20)
Save
Tweet
Share
17.49K Views

Join the DZone community and get the full member experience.

Join For Free

Upsidedown-2016-08-4-10-32.jpeg

In the software development world, a number of common management maxims need to be reversed if one is to be an effective manager. Those who manage software development — and I include all the non-commissioned managers in this, Architects, Team Leads, Scrum Masters, etc. — need to turn their thinking upside down.

Here are a few I spot all the time but I’m sure there are more:

1 - Diseconomies of scale: larger teams are less productive per worker than smaller teams, larger code bases are more expensive to maintain (enhance, debug, change) than smaller code bases per unit of code, large requirement requests (documents) are more expensive per request than small requests and so on.

2 - Higher quality is faster, there is no such things as “quick and dirty”: delivering quality work is faster than delivering shoddy work because shoddy work needs fixing. Even if the first low-quality piece of work does arrive more quickly, the second will take longer because the first gets in the way. Each shoddy piece of work will cost more because subsequent work will take longer.

Software product has many “qualities”: functionality, speed of execution, usability, etc., etc. What constitutes quality varies from product to product, however… all software products exhibit two qualities in common: number of defects (bugs) and ease of maintenance (maintainability). When I talk about quality it is these last two items I am talking about.

Whenever you find a high-performing software team you find a high-quality code base (low defects, high maintainability). Hardly surprising if you have read the work of Capers Jones and Kent Beck.

3 - Teams over individuals: There are times when a lone developer can sit up all night and deliver a world-beating product. Particularly at the start of a new technology: think Nick D'Aloisio writing Summly, Matthew Smith writing Manic Miner, or Dan Bricklin and Bob Frankston writing VisiCalc in two months.

We admire people like D’Aloisio, Smith, and Bricklin but they are poor role models. Most serious software development is a team sport. The characteristics which make the lone developer successful are a disadvantage. Managers who believe in the Lone Hero Developer model do everyone a disservice.

The constraint in developing software is not typing speed, it is thinking speed. We need people who can share, who can discuss, who can work together. That is why Pair Programming can be far more effective than solo programming and why Mob Programming is on the rise.

4 - Doing is the quickest way of learning: when processor cycles were expensive and difficult to get (think 1970, IBM mainframes, OS/360, IMS hierarchical databases and less than a dozen internet nodes) it made sense to think through every possible angle before developing something. Back then most systems were a lot smaller than they are today.

Today processor cycles are cheap, you have more CPU power in your pocket than Neil and Buzz took to the moon.

The quickest way to find out if a technology can do something, the quickest way to learn a technology, and the quickest way to find out what customers think is to just do something and see what happens.

There is a place for planning, but planning has rapidly diminishing returns. A little bit of planning is valuable, but a lot is counter-productive: the return from lots of planning is minimal and it delays learning by doing.

5 - Do it right, then do the right thing: modern development is inherently iterative. If a team can’t iterate they cannot perform. If we are to learn by doing we must iterate: plan a little, do a little, review the results, plan a little, do a little….

“Customers don’t know what they want until they see it”

Or perhaps:

“Companies don’t know what will succeed in the market until they ask people to part with money.”

Again and again, we see that customers need to be shown something in order to understand what a product can do for them. And again and again we see that until a product is in the market and customers are asked to exchange money for it the true value, the ultimate “doneness” cannot be judged.

Only when we are in the market, only by showing what we have, can we refine our ideas of what is needed and what is valuable. And when we have this information it is through iteration that we act on it.

If the team can’t iterate (do it right) then they have no way of learning and validating their plans. Sure, doing the wrong thing effectively is pointless, but the only way to find out what is right and what is wrong is to do something, anything, and iterate.

6 - Worse is better: the famous Dick Gabriel from 1989:

“the idea that quality does not necessarily increase with functionality—that there is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.”

-https://en.wikipedia.org/wiki/Worse_is_better

Sometimes creating a worse product is a more effective strategy than creating a better product. Building a better mouse trap is rarely the route to success.

To a business mind this maxim sometimes seems obvious but to an engineering mind, it is shocking.

And this final maxim means that all of the above propositions are sometimes reversed.

(Many thanks to Seb Rose for comments on an earlier draft of this post.)

Software development scrum

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • A Beginner's Guide to Back-End Development
  • Top 10 Secure Coding Practices Every Developer Should Know
  • Top Authentication Trends to Watch Out for in 2023
  • Web Application Architecture: The Latest Guide

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: