“Worst software is a management issue,” a government software developer talks about how to make good software


by

Austin Distel

`` If bad software is born, the problem is often in management, not in specific engineering, '' said Li Hongyi, who is developing technology for the public security sector in Singapore after working as a product manager at Google. 'How to build?'

How to Build Good Software
https://www.csc.gov.sg/articles/how-to-build-good-software

Hongyi said in a single sentence the problem of terrible software development: “ Starting software construction as a solution without clarifying the problems that the project owner should solve, and developing a long list of requests from stakeholders in full scratch To an external development team that wants to do this. '

On the other hand, good software development begins by clarifying the problem you want to solve. By clarifying the problem, it is possible to test possible solutions and take an appropriate approach. And since there are many open source communities today, it is important to make good use of existing code rather than trying to create software with full scratch. The reason is that if the engineer's time is taken to reconstruct existing technology, technological progress cannot be achieved. Hongyi said it is important to automate routine engineering as much as possible, identify a system that is suitable for reuse, and customize it to suit your needs.


by

Pankaj Patel

It is not the amount of resources that determines software, but rather the ease of use. In many cases, systems with many functions are disliked, and apps that are highly appreciated for simplicity tend to be on top of the popular rankings. In order to confuse users as more and more new features are added, Apple's iTunes was finally split into three parts: music, podcasts, and TV shows.

As project complexity increases, the engineering process itself stops. The more the code base of the app, the more bugs will be created each time a new feature is built. This is called “ technical debt ” and is a major challenge for large IT systems. Such systems often have problems that have not been fixed for years.

And even though the software looks simple at first glance, there are usually many ideas and prototypes to get there. Apple has gone through dozens of prototypes before the final product is released. There are many decisions to make before the final decision is made, and complex knowledge is needed to make the decision “why a particular solution is chosen”.


by

Shahadat Shemul

It is the accumulation of such “knowledge” that is important for software development. When one development team takes over the code of one software, the quality of the software often falls off visibly, because a development team unfamiliar with the software repeatedly corrects the problem in time. . The additional code in time creates new bugs, confuses the user interface, and ultimately complicates the entire system. This is why it is difficult to outsource the development of core software.

Based on the above, “Three Principles of Excellent Software Development” advocated by Hongyi is as follows.

◆ 1: Start as simple as possible


by

Bench Accounting

The key to creating good software is to start with the simplest solution. Multi-function apps such as Facebook and WeChat also started with specific features and gradually increased in functionality as they gained popularity. Software projects are not “collapsed because they are too small”, but are often “collapsed because they are too large”.

In addition, there are cases where a large number of request lists are sent from stakeholders, and this should be prioritized, such as “whether it is an absolutely necessary function” or “high value-added”. about. Hongyi says that people who want to increase the priority of functions will naturally consider lowering the priority of other functions, so discussions will be easier.

◆ 2: Finding problems


by Hans-Peter Gauster

To make good software, you need to make 'bad software as a base' first so that you need a draft when you write a paper. And from there, it is necessary to understand the root of the problem correctly. For example, at the beginning of the project of `` Parking.sg '', a government-sponsored parking ticket application, the development team thought that the problem to be solved was `` the police officer feels annoying the paper parking ticket '' However, when I actually talked to the people in the field, it turned out that there was no such problem. One dialogue saved a few months of wasted effort, and he was able to concentrate on a “driver assistance project”.

The team later found out that the root of the Parking.sg project's “drivers feel frustrated when dealing with parking tickets” is that it ’s difficult to find information on government websites. . By clarifying this problem, it seems that it was possible to test the feasibility of a solution to the problem and build an actual product.

In addition, no matter how many times you repeat the feedback, the actual product may have problems that did not occur during testing. Problems that occur only 0.1% of the total do not manifest during the test, but if you have 1 million users, 1000 will encounter the problem. It is recommended that you use both a quick feedback group that requires relatively minor corrections and a feedback group that solves a wider range of problems over time and expense. “The key to building software is not avoiding failures, but failing as quickly and strategically as possible,” Hongyi says.

◆ 3: Employ the best engineer possible


by Max Duzij Follow Message

Companies like Google, Facebook, Amazon, and Netflix are in a fierce competition for talented engineers, and even new graduates can get high salaries. Facebook's CEO Mark Zuckerberg and Apple's former CEO Steve Jobs said `` The best engineers are at least 10 times more productive than the average engineer, '' but this is the speed of writing code Does not mean that is 10 times, but it means you can save 10 times your work by making good decisions.

A good engineer has a good grasp of reusable software and minimizes the need to build with full scratch. You can also automate routine tasks and build a system that is easy for other engineers to understand. This allows people around you to work quickly and reliably, giving you time and allowing engineers to focus on creative problem solving.

A small team of good engineers outperforms a large team of average engineers in productivity. The completed software has few bugs and security issues, and the system will be concise, consistent and easy to understand.

in Software, Posted by darkhorse_log