Embedded System Engineers must work smarter

Embedded System Engineers must work smarter

Embedded System Engineers must work smarter

15:03:46 favorites | print | vote (6) | comment (9) | read (15315) ◇ Font: [large, small] compiled from Jack ganssle, author of embedded.com

Not long ago, Kirk, a good friend in the real estate industry, read Tracy Kidder's new machine soul. This book describes how data General engineers have produced eclipse computers in a record. Kirk thinks this is an interesting book, well written, but he is saddened by the high-pressure production plan and exhausted people. He said something surprising to me: "I can't believe that the high-intensity schedule described by Kidder is true, and no one can work like that for a long time ."

How can I explain to a person who has no connection with the tech field that the schedule has always been our biggest headache? In my career and almost all the engineers I know, the deadline for every project we do is capricious and impossible to complete? In recent years, the timeline has shrunk more. Based on today's standards, the Kidder statement can be said to be too gentle.

As a result, I think that people not in the technology industry may have no idea how we can be driven crazy by an impossible deadline. Is our industry unique? How many other industries have such long-term and relentless pressure to make things faster? Is regular and unpaid overtime also the subject of other economic sectors?

Relatively well-developed project management software appeared in 1980s. Anyone can enter a complex PERT (Planning Review) and Gantt diagram. Who can use this successfully? I have seen countless developers trying to build timelines around the deadline set by the market. They hope this schedule is credible, but they are completely aware that it is impossible. When I was in middle school, the church of Jesus sent a transcript on Friday afternoon. We will extract the transcript from our mailbox and wait until Monday to re-plug it back so that the weekend will not be destroyed. This is just a childish little trick to postpone the inevitable things, and this is exactly what engineers have done.

The project progress planning software is promoted as an advance in the original manual tools. Now, we can create error data more quickly. This is the beauty of the Computer: it used to take several seconds or even a few minutes to make a mistake, and now thousands of errors can be generated within one second.

People have been writing software for more than 50 years, and they have been developing embedded systems for 30 years. What remains unchanged during this period is the performance improvement under the tight schedule.

We try to deal with three conflicting tasks: Impossible schedules, too many expected functions, and quality. If one of the three legs is removed, this project will lose value. Can we keep many bugs during shipment? If the answer is "yes", it will be very easy to deliver on time. Can we ignore the shipping time? If we have unlimited time, we can improve every function.

This tangle of three has become a hidden danger from the very beginning, but developers and managers cannot recognize the facts covered by the conflict. Without exception, the boss wants all three legs: delivery on time, perfect quality, and endless functions. But he cannot get all.

The logical idea is that we must emphasize functionality because there is always no room for discussion about schedule and quality issues. Use the demand elimination method to identify and remove functions that are not actually needed. Establish a system in a systematic manner, so that even if you lag behind the plan, you can still come up with products that can well complete most of the important functions.

Of course, there are other factors that affect the development environment: resources. The combined tools, enough excellent developers, and enlightened management teams constitute the infrastructure we need to complete the project.

In the 20th century, we learned how to build an embedded system, but management has never figured out the proper position of resources in the development project. Engineering Projects are often seen as manufacturing gadgets on production lines. Do you need more products? Then join more people and more machines. However, this is not feasible in the software engineering field.

Fred books shows a phenomenon in his book "man-month Shenghua" (note: "man-month" refers to Ai In January): to add people to a lagging software project, this will lead to a longer lag. There is only one communication channel between the two developers, but when there are more engineers, the number of links for Memo/meeting/email will increase with the number of people.

IBM found that software productivity decreases significantly for the same reason as the scale of the project expands. Their survey showed that code production (line/day) dropped by an order of magnitude as the project expanded.

Barry Boehm's constructive cost model is the most famous software planning prediction model, which also shows that the timeline is growing much faster than the firmware size. By multiplying the number of lines of code by 2, the delivery time will be much more than doubled. Sometimes more.

However, when a project is in trouble, "hire someone again" seems to be a common management motto. But it does not work.

Is there no hope? Is our project doomed to fail? Is the stress described in the soul of new machines our fate?

As the complexity of the project increases rapidly, it is obvious that unless we devote ourselves to a brand new development model, otherwise everything we 've learned about software engineering over the last half century will hold us up, degrade, and ultimately fail. Companies that accept new thinking models (and verified old ones) will be successful. In particular, there are two key points for new understanding: Reuse and tools that will be discussed in this article.

Tools

In 1940s, all software was written as machine code. In 1950s, we witnessed the first compilation language: Fortran, which improved programming efficiency almost overnight. The cost of using FORTRAN is a larger and slower code, which was considered unacceptable by too many engineers at the time. But those who accept Fortran prove to be pioneers in the future.

Today, we have heard a similar debate about modeling, C ++, and Java. Too slow and too large. But it is obvious that the creation of millions of lines of C Programs cannot solve any problem. To catch up with the increasing demand for products, productivity must be improved, and manual code writing does not provide such an improvement.

Advanced languages give us the ability to abstract and build projects at a higher level. Abstraction is the foundation of the future. We can no longer worry about bit and byte because the cost is too high. Whether you like it or not, the Windows API does provide a lot of resources for desktop developers.

Tools of various styles can abstract the details at the bottom layer. The first Fortran compiler, in today's standards, is simply so ridiculous that it gave engineers powerful weapons in 1950s. Now we have more options.

We basically accept the additional overhead of the compiler. Other tools with higher abstract capabilities bring more overhead, but also faster and better delivery capabilities. Modeling tools, such as UML, are used in some fields for success. Few developers fully understand Labview and MATLAB, and they play an important role in the embedded field.

Tools that can automatically search for bugs will further increase programmer productivity. Coverity, klocwork, polyspace, green hills, and grammatech are all pushing them to find static analyzer with runtime problems. Of course, these tools cannot find all bugs, but they provide a weapon to deal with schedules, although so far the market penetration is still low.

Reuse

Tools that allow us to write more code faster are only part of the solution. Obviously, a new Reuse Model is urgently needed. For a product consisting of millions of lines of code, it is too slow to compile a link in one line.

Some outstanding new developments in software engineering are blocked, so they will certainly be reused in the future. Unless we can ask for, borrow, steal, or buy a large number of code libraries, we will always have to write each line on our own. This is intolerable.

Reuse not only saves some code in the previous project, but also recycles the firmware that exceeds 20%. Systems with more than one million lines need to be reused to the maximum extent.

Let's define several specialized terms to illustrate what is reuse and what is not. Software recycling refers to the use of code that is not designed for reuse. That is, extract a part of the old resource and put it into the new application.

The Code is to port the firmware from the previous project to the new project. Like recycling, this is usually a reckless source code.

The real reuse is to create a component at a time when building a system, not just a row. These blocks have been clearly defined, so you do not need to go deep into the interior for adjustment, debugging or optimization. Richard Selby found that when the old code is transplanted to a new project, if more than 25% is modified, the project time cannot be effectively shortened. Reuse is most effective only when it is used in bulk.

A package must be reused at least three times before it can be viewed as truly reusable. In other words, domain analysis is difficult. We are not smart enough to really understand the scope of the application. Each domain must have its own unique functions and features. When we use the code multiple times in a wide range of applications, to make it universally available.

From this we can see that reuse is very expensive. We spent a lot of money to produce very good code, but it only paid off when we reused it three times. How many of us are patient and disciplined-and time-writing code for future use? Reuse is like a passbook. If you do not deposit enough money into your account, it will be of no value. The more you invest, the more you return.

When can we get most of the applications through purchase instead of writing them from scratch? Is Software IC really possible?

The future belongs to those brave and smart enough to discard old thinking patterns and create new ideas. We will find a way to design the product by using the previously written code. The advantage of doing so is obvious. The practice of building a system in one line should be stopped. This may mean adding resources, storage, and high-end CPU in low-end applications; it may mean new tools. Of course we will design the system in different ways. Although some implementation details are still unclear, the results are very clear.

The biggest change will be our attitude and the way we develop products. One day, with the support of the Management Department, we will realize two important things: firmware is the most expensive and code can be written by dummies. In the future, developers looking for better product development methods will not be experts in programming.

Therefore, I want to say to my friend kirk and all those who are not engineers that we are indeed working under a huge schedule. This is because of your needs. Your digital anti-shake binocular telescope, $100 worth of GPS, digital cameras, and all other electronic products that make up your world, all come from these engineers who struggled before the deadline and developed surprisingly cheap and reliable systems.

When you use one of these systems, think about us occasionally! We are sitting in the lab and working for the next version.

The author introduced: Jack ganssle is an instructor and consultant in Embedded System Development. In a questionnaire survey conducted by embedded.com, Jack ganssle was selected as one of the most important figures in the embedded field in the past 20 years; other candidates include Linux creators Linus Torvalds, Wind River founder Jerry Fiddler, and Steve Jobs, Gordon Moore, and GNU program initiator Richard Stallman.