Bad Software, Worse Solutions: Programming Will Always Be Hard
Published: 08/09/2012
Software Runs the World: How Scared Should We Be That So Much of It Is So Bad?
The article is not a big deal but the comments were really interesting, especially all the PhD's in Computer Science who said following formal methods would make it all better, plus the usual folks who want regulation and certification and licensing.
All I could think of was "good luck with all that". After 30 years of writing code for a living I feel secure in saying that there is no silver bullet, no magical method or paper guarantee that will make all software perfect and bug free.
In fact it's even difficult to define what a program is, much less describe how you would go about developing perfect programs. Software lives in so many realms, is written in so many environments, languages and businesses, and interacts in multitudinous and often unpredictable ways that there isn't any easy way to even find a formal definition of what comprises software. Try to find common ground between iPhone games, high speed stock trading systems, your toaster and a Mars lander. Try to license programmers in Assembly, C, Java, PHP, Fortran, LISP and Erlang. Now add multiple language web applications and client/server and distributed systems.
That's one mighty bunch of stuff to try to describe formal methods for; just listing all the programming languages is mostly impossible much less explaining how to write perfect code in all of them.
I love when people try to compare programming to something like civil engineering. Building a bridge has not fundamentally changed in two thousand years; you deal with gravity, wind, rain and heat and many basic materials that would be familiar to a Roman engineer. In programming we have to create our own universe for every program, or probably a better description would be we adapt some collection of universe elements that are combined to simultaneously construct a hundred different bridges which all have to work together even though the universe may change unpredictably later.
Even worse is that a bridge may take years of planning and construction time, and then last for a 50 years without alteration. Software evolves constantly, both during development and afterwards. There are around 600,000 bridges in the US, built over two centuries. There are nearly a million iPhone apps all of which were written in the past 5 years. Programs come in all sizes from a few lines of code to tens of millions and touch every single area in modern life.
What makes writing software so hard is that it can be almost anything and anywhere, affect one person or a billion, have to work flawlessly for decades or only once. It's nothing like a bridge or a building. The Mars Lander is millions of lines of C written for exactly one use. High speed stock trading software executes trillions of times one microsecond at a time.
The idea that there exists a set of formal methods that if followed ensures a perfect result for every kind of program is ludicrous. Even if such a perfect miracle were possible the cost would make it impossible to ever use it. Even if you could formally prove a set of source code where would it run? An operating system you don't control? Calling web services from some other company? Interacting with users who are real people? Built with a compiler running on a CPU you didn't design talking to other electronics that didn't exist when you proved your software?
I think I'd believe you have a time machine to sell me before I believe that your formal methods can work in messy real world.
The other white lie is that we can come up with a way to formally prove that the programmer can write perfect code through testing, licensing and certification. Programmers aren't plumbers. Plumbers deal with water, gases, pipes and valves. Like the bridge ingredients these things rarely change; after all fluid physics is a well known science and unlikely to spontaneously become something else.
I knew a guy who passed all the Java certifications yet when put on a real application was hopeless; he simply didn't get how to write a real body of code. Now imagine trying to certify someone in all programming languages, including ones not even invented yet! Add to that certification in every kind of program from toasters to spaceships. Either you create useless generic certifications or some that are so specific the certified are unemployable. Combine that with constantly changing needs for programmers and what do you do when you need something new, fire everyone you have and get all new people?
At work the UX designer and I are helping to mentor a group of Java web programmers in iOS development because we have more iOS needs than we have people. It's hard for even experienced programmers to do something radically different on the fly. Assuming we would need formal methodologists and certified iOS programmers to compete in our market we might as well close shop.
The new iPhone app we are developing with 3 of us (all experienced in iOS) in two months at a breakneck speed with constant changing requirements would not be possible unless we could actually deliver something fast enough to stave off the competition. Expecting some formal proof of all the code before shipping is a nightmare of a pipe dream. Who cares if it's certifiably perfect if it ships years after the company is gone.
Reality can certainly bite. Over the 30 years of real coding I have done I am confident what I have written is pretty good. During 1987-1994 I was responsible for writing (along with many others) and making the final decision on binaries delivered to a floppy disk duplicator for 11 major releases of 3 Mac applications and never once did we have to have a redo (Deltagraph alone cost nearly $1 million to duplicate and ship per release). Was the code perfect? Were we certified Mac OS C business/graphics programmers? No, and no. Were the applications useful and allowed people to do their business or whatever without too many irritations? Yes.
Does this prove anything? No. But good code is possible and does happen, and often from people with no license, degree, guarantee or formally proven skill.
Maybe someday a robot will write all software and prove it beyond any possible source of error and all humans will live happily in perfect software land.
Me, I'm betting on a time machine happening first. With software written by humans.
Tag: programming
分享到:
相关推荐
* TCD 14从 MICON 当机A2TCD:电梯控制系统中的MICON部分存在当机故障。 3. 马达故障 马达是电梯的主要驱动装置之一,负责将电能转换为机械能。常见的马达故障包括: * TCD 20双重入力 BUFFER 故障A1○TCD:马达...
- **制造商承诺**:Micon Technology Inc.(以下简称“MICON”)向原购买者保证,在正常使用条件下,iGuard IP摄像头产品线在硬件方面无设计、制造及材料缺陷,保修期为自原始购买之日起一年。 ##### 2.2 原购买者...
3. TCD 14 从 MICON 当机、TCD 15 SDA 当机:MICON和SDA是电梯控制系统的重要组成部分,当机可能意味着控制系统的软件或硬件出现问题。 4. TCD 16 主从并列通信异常、TCD 17 SDA, SDC 串行通信异常:通信故障表明...
* 入力BUFFER调查:主MICON ZX50BM($CA01H),从MICON ZX50BS($CD21H)之DATA是否随50B继电器的ON/OFF同步动作。 * 出力BUFFER调查:电梯停止时,50B继电器的测定。 解决方法: * 更换FIO PCB:如果50B继电器的故障...
2. TCD 14-16:从 MICON 当机、SDA 当机和主从并列通信异常代码,表示电梯控制系统中的通信故障。 3. TCD 17-20:SDA、SDC 串行通信异常、SFCCK 故障和 PSFCK 故障代码,表示电梯控制系统中的故障。 4. TCD 21-25:...
mIcon1 : mIcon2); return newView; } ``` 这种做法在数据项数量较少时可能还能接受,但随着数据的增长,频繁的View创建会导致性能急剧下降。 为了优化,我们需要重用已经创建的View。这就是convertView的作用。...
- 解决方法:重启从属MICON控制器,如果问题仍然存在,则需要进一步检查硬件是否存在问题。 6. **TCD15: SDA当机** - 内容:SDA(静态门控 amplifier)出现死机状态。 - 等级:A2 - 解决方法:重启SDA控制器,...
4. TCD 14 - 从MICON当机:主控器的子单元出现故障,需检查子控制器的硬件和软件状态。 5. TCD 20 - 双重输入BUFFER故障:可能涉及数据传输错误,检查缓冲区及数据通信线路。 6. TCD 21 - 过电流检出:电机过载,...
mIcon1 : mIcon2); return item; } ``` 这是最简单的方法,但也是最慢且最不实用的。 - **方法二:利用 convertView 回收视图** ```java public View getView(int pos, View convertView, ViewGroup ...
5. TCD 14 - 从 MICON 当机:从控制器(MICON)出现故障,影响电梯的协调工作。 6. TCD 15 - SDA 当机:SDA(System Data Access)系统数据访问出现问题,可能与系统内存或处理器相关。 7. TCD 16 - 主从并列通信...
4. TCD 24 从 MICON DPRAM ERROR:从控制器的动态随机存取存储器(DPRAM)出现错误,可能影响电梯的数据处理和通信。 5. TCD 38 DSP 当机检出:数字信号处理器(DSP)发生故障,这是电梯控制系统的关键部分,需要...
然而,原有的自动化控制系统存在一些问题,如PLC与MICON-200之间的通讯性能不佳,依赖于复杂的直接连接,容易出现故障。此外,MICON-200系统维护困难,对环境要求高,使用寿命短,控制板通用性差。PLC系统在恶劣环境...
6. 通信故障:TCD16、TCD17、TCD25涉及MICON(微电脑控制器)之间的通信问题,可能导致电梯停止运行或无法正常控制。 7. 电源问题:如TCD28的P15V电压异常、TCD34的不足电压检出,表明电梯供电系统存在问题,需检查...
【麦肯8位单片机】是MICON公司推出的一款高性能、高性价比的单片机系列,它与PIC单片机系列完全兼容,具备较强的抗干扰能力,可以在宽温范围内和低电压条件下工作,因此在市场上的应用广泛。该系列单片机的主要特点...
mIcon = findViewById(R.id.badge_icon); mCount = findViewById(R.id.badge_count); } public void setIconBitmap(Bitmap bitmap) { mIcon.setImageBitmap(bitmap); } public void setBadgeCount(int ...
- **TCD14 MICON A2**:MICON(微控制器)出现异常时,触发此故障码。微控制器是整个系统的核心组件之一,需要密切关注。 以上只是部分故障码的解析,针对不同的故障码,维修人员应按照实际情况采取相应的处理措施...