Software applications exist to perform a wide variety of tasks and for any given task there are many applications to choose from. As anyone who has visited an “App Store” knows, the number of available applications can range from a select few to thousands. Your performance criteria provide a means of selecting the best application for you or your company.
Customers will question whether your application is worth the investment of both money and time. It is from this perspective that lean code serves the programmer’s objective to deliver maximum value to ensure the customer is satisfied with their purchase. Those who buy from the App Store are only concerned with two things:
- What can it do for me? and
- How much does it cost?
The customer’s perspective quickly changes after the purchase to:
- Did I get what I paid for?
- Does the app perform as expected?
Lean serves to maximize customer value through the elimination of waste. To some, this translates to providing a low cost application in the shortest time possible. From our perspective, lean translates to an application’s ability to perform to customer expectations.
Performance Matters
In our view, lean code is determined by an application’s performance – “speed of execution” – not development time. It is possible to write a fully functioning application in a relatively short period of time using a high level programming language such as Python. However, the performance of the application may be substantially less than that of an equivalent application written in C.
The best choice of benchmarks to measure performance is real applications… Attempts at running programs that are much simpler than a real application have led to performance pitfalls. – The Computer Language Benchmarks Game – Toy Benchmark Programs
When personal computers were first introduced to market, they were slow, cumbersome, constrained by memory, and disk storage was extremely limited. The need to write “tight” code to provide as many features as possible was a given.
Today, computers have an abundance of memory, storage, and processing power giving rise to bloated software applications that are more feature focused and not necessarily performance driven. A simple “HelloWorld.com” program could be written using debug and required only 17 bytes. By comparison, the most basic “Hello World” program written in the GO programming language compiles to create a 1,624,576 byte “.exe” file.
Programming Languages
Performance implications of the language used for a given application cannot be underestimated. Consider that the C programming language is consistently used as the benchmark by which all other programming languages are compared. Unless you are programming in Assembly Language, few languages can touch the performance of C.
This is not to suggest that performance is solely dependent on the programming language used to create the application itself. The performance of an application is as dependent on a programmer’s knowledge and ability to effectively apply the capabilities of the selected programming language to efficiently perform a given task.
Speed of Execution versus Development Time
Sorting data is a common requirement for any software application and there are a number of algorithms to choose from including: Quick Sort, Bubble Sort, Selection Sort, Insertion Sort, Merge Sort, In-Place Merge Sort, Introsort, Heap Sort, Comb Sort, Bucket Sort, Radix Sort, Tim Sort, Library Sort, and Counting Sort.
The algorithm selected by the programmer will determine how efficiently a sorted list can be generated. A bubble sort is relatively easy to implement and requires minimal development time but executes slowly whereas a quick sort may require more development time but executes very quickly. In reality, the best sorting algorithm is not one but a hybrid of multiple algorithms combined into a single sorting solution.
Building Blocks or Stumbling Blocks
Interpreted and high level languages are made possible by the continued development and availability of numerous modules, libraries, frameworks, and API’s (Application Program Interface) and can save programmers a tremendous amount of time and effort when developing highly complex applications. Unfortunately, this can also give rise to increasing demands on the resources such as available memory and can impede an application’s performance.
All of the advancements made to simplify and reduce development time give rise to increased functionality that may not necessarily be required by the application. Either a developer must attempt to write their own interfaces or potentially suffer the consequences of having to use the packages that are available.
While it is easy to implement and use various packages, another downside is not fully knowing what is really happening behind the scenes. As we have already noted, a number of algorithms are available to sort our data. It is a simple matter to write “sort (‘a’, ‘d’, ‘e’, ‘c’, ‘b’) and expect that the list will be sorted correctly, however, we have no understanding of the algorithm used to return the result.
Economies of Scale
One reason for concerning ourselves with algorithms and our code’s speed of execution is to understand whether our application will scale, especially where high volumes of data storage and retrieval may be realized.
Excel is a widely used spreadsheet application that is capable of working with relatively large data sets. For relatively small data sets, Excel is the perfect solution and offers a vast array of capabilities to work with our data. However, as the spreadsheet continues to grow, performance begins to suffer. In addition, the size of the data set is limited. In contrast, a relational database management system such as Microsoft’s SQL Server can easily manage millions of rows of data across a wide ranging number of tables.
Although the applications share a certain perceived level of common functionality, they are radically different in their implementation and capabilities. If you have the opportunity to use SQL Server, you will note the emphasis on execution plans and performance. However, as we have already noted regarding language skills, there is a stark difference between knowing SQL and using it to write effective and efficient queries.
The Best of Both Worlds
The point of comparing Excel and SQL Server is to recognize how each application provides value to the user. Excel is feature driven and able to work with moderately sized data sets whereas SQL Server is performance driven, offering relatively few features and able to work with extremely large data sets.
For this reason, it is not surprising that Excel can connect to SQL Server as a data source. The user can now have the best of both worlds where highly efficient SQL Server Queries can seamlessly provide data to a workbook or worksheet where the feature rich capabilities of Excel can be applied.
This comparison between Excel and SQL Server also demonstrates that not all aspects of programming require the same level of code optimization. There is not much that can be done to improve the efficiency of a process where the application is waiting for the user. As such, the “value stream” should focus on code where the user is waiting for our application to complete a given task.
Lean Code
To cite from The McGraw-Hill 36-Hour Course “Lean Six Sigma” by Sheila Shaffie and Shahbaz Shahbazi, ISBN 978-0-07-174385-3, the following statement can easily be applied to application development from a “Software as a Service” (SAAS) perspective:
Lean Six Sigma is based on the premise that in order to deliver service and product excellence, firms must not only have an in-depth knowledge of their internal processes, but also have a profound understanding of customers’ current expectations and future needs.
Although we have only touched on a few elements of Lean Code, we have identified the need to provide our customers with high performance solutions that will scale to meet their growing demands. Processes are not only those used to run our business but also include the underlying processes or value streams that comprise the code in our applications.
Lean thinking applies to all facets of our business from customer service and operations management to software development and application performance. Increasing value to our customers and our stakeholders is the objective of our lean initiatives.
Until Next Time, STAY lean!
Related Links:
1 thought on “Lean Code – Part One”