Why is Programming so Hard? – Incidental and Accidental Complexity

by

Accidental complexity can be referred to as technical debt or sometimes spoken about as incidental complexity – ultimately there is a difference between conscious and unconscious sources of poor code. If it is deliberately decided to deliver suboptimal products, there is a perceived hurry to ship to market. If there is a strong enough incentive to pay the cost of rushing a product, the scenario incurs technical debt because there was a conscious decision to incur that debt. However, this post points out that often when speaking of technical debt, the poor code is not a result of expedited release but because of poor skill or lack of understanding – all in all this code is not tech debt but is sloppy code.

The post recommends speaking about whether lack of quality in code was intentional or not by calling the lack of quality “lack of craftsmanship”. When looking at source code sometimes there is a complexity present that could have been avoided if there were more time, money, or skill. This post states that figuring out the difference between sloppy code and technical debt doesn’t really matter, as the actions needed to resolve the problems caused by both are the same. As long as there is an awareness of the distinction between releasing ‘too early’ for different reasons and that there is always room to improve skills in order to avoid unnecessary complexity.

To read the full post go to: http://xlntconsulting.blogspot.ca/2014/11/why-is-programming-so-hard.html

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|