OSNews

You misunderstand what I mean by discipline.

Traditional Software Engineering - and even present thought on Software Engineering - is dead wrong. It doesn't work, and it's not practical - too laborious and too costly.

Rather, I am arguing that certain aspects of Traditional Software Engineering are good, and helpful (e.g. Concept Of Operations, Requirements, Architecture, Design, etc.); but not necessarily as they are now. They are good and helpful namely because they force communication to occur so that both sides understand what is being delivered in plain language. They also provide something both sides can test against and say without doubt that what was agreed to has been delivered.

However, while the "art" surrounding those documents is pretty much already settled - since it applies to far more than simply software - there is a whole other side to engineering that software presently lacks - and that is simple discipline in the field, of which those documents are merely a part.

Software today is (i) highly unreliable, (ii) highly buggy, (iii) a support nightmare, (iv) very costly to produce, and (v) late on delivery if it is even delivered. Most software projects - even small ones - are vastly over budget; and the majority fail ot even make it to delivery. But that need not be the case - software CAN be reliable, with few bugs, on budget, and on time; but we don't get there without discipline.

I'm talking about discipline similar to how one is disciplined about driving a car. There are certain norms - e.g. drive on the right side of the road, etc. You need those norms to provide a good experience, and do what is necessary. With respect to software, the programming language IS NOT one of those norms. Rather, the norms apply to the coding style, how the logic is layed out, etc. In other words, how the programmer does the job of programming. They need not be overly burdensome, but they do need to make code more uniform at least at the company/team level. (I say company/team because when working for an employer, it should be defined by the team of programmers working for the employer - all of them; however, when working on a multi-company project or on a project not related to a company, then it must be defined instead by the team of programmers working on it.) By providing uniformity, more people are more easily able to spot the problems.



Fair enough; I think I may be a little further along than you, but not necessarily by much. I'm all ears, and I'll certainly try to incorporate what I've learned into what I am working on.



Okay, you actually have two multiple things going on here. First, I very much do agree that software is a very different beast than any other engineering field; first and foremost because it is in a very different environment than any other engineering field. In all other engineering fields you have very exact physical limits - e.g. the law of gravity, the structure of a cell, etc - where as with software, you have to create your universe nearly from scratch for every project, well not quite any more since we mostly write for one or more operating systems that do provide some continuity in the environment. So to compare - civil engineering is predictable because the laws of physics never change; but software is far less predictable because the environment is constantly changing (e.g. what other software is installed, the hardware it is run on).

Building Codes equate more equally to programming languages. They don't come very often, and they seldom change.



You get the structural engineering part write, but still fail at the software engineering side.

There is nothing prohibative about writing a standard set of procedures on how to program. I would not say that any programming language itself should be standardized upon - indeed, no single language works for every instance of application implementation. However, procedures for writing a program can be.

For instance, consider how one implements an algorithm. Do you check the error condition first? Or do you check the success condition first? How do you handle the errors? Do you check inputs to see if they are valid? Do you check pointers? There are a lot of little details like those that can be very easily standardized upon, details that after being decided upon aid the programmer in keeping from creating bugs in the software, and they do not prohibit the advancement of software development in any manner - rather, they promote it.

Again, going back to the questions I asked in the last paragraph, think of how many different answers you can come up with just from that small set of questions, and there are many more that need to be addressed. Standardizing on things such as these will enable coders to do more - code will be more quickly written, and more easily verifiable - not just be tools, but by people as well.

Furthermore, you increase what I call your "Bus Factor". That is - if you are the only one working on a given piece of code on the project, and you were to get hit by a bus today - (i) would someone else be able to pick up your code and continue, and (ii) how quickly would that be able to happen? By standardizing, you enable someone else to be able to pickup what you are working on, and continue it, and you decrease the time it takes them to figure out what you have been working on. (BTW, I've done just that 3 times already - first time for someone who was fired, second time for some that literally died, and the last time the guy quit.)

Programming such that you are the only programmer to be able read and understand the code is NOT professional. It can be guaranteed that you will not be the only programmer on the project; so humble yourself and write your program with that in mind. More likely than not, the next programmer won't be as smart as you so it needs to be clear enough that someone with lesser experience can pick it up - they won't be able to read your mind, especially if you got hit by a bus (e.g. died).



Very much agreed.



UML has a strength - it can represent something in a graphical way. However, it's greatest weakness is change. Software changes rapidly during development, and UML will quickly become outdated. Even if the initial UML model was able to express every detail necessary, by the time the coders were able to get just the initial coding done it would be outdated - things would have changed - there would be more functions or less, more classes etc.

[q]I would argue that too little detail leaves your design open to error and misinterpretation but that too much solidifies it in the face of changi