Author Joel Spolsky is a great thinker on how to write good code.
As a C++ programmer I do feel I have to take issue with his arguments against C++ exceptions. You can regard the C++ Exception as a “goto” with an unknown destination. This does sound like a recipe for a “bad smell” in your code. But C++ Exceptions are designed for handling errors that occur in a self contained part of code that can’t know what the correct way (because it depends on the time of usage) to behave when the error is encountered. By passing back an exception it allows the calling code to decide how to handle the error condition. This is an invaluable tool when used correctly. C++ Exceptions are great for solving this design challenge. But please don’t use them for anything else. Any other use immediately drifts into the problem area discussed by Joel Spolsky in his document.
I have customers who ask “When will the software be finished?”. I have more experienced customers who ask “When will the software be ready to use?”. The previous posting was heading to the conclusion that software is very very rarely actually “finished”.
You need a bit of software. So it must be doing some kind of useful task. Parts of the software may very well be useful in the future (even as part of a solution to a completely different task).
It’s a failure for all concerned if software has to be consigned to the “Recycle Bin” because it has become “so tangled and uncontrolled that it is no longer maintainable or useful” . If you are investing your time (or your money to pay for someone elses time) you want your investment to be worth while. This is achieved by taking time out to plan how to avoid “case b)” and to design according to you plans.
Do use Unit Tests. Do think about how you are going to test the overall software operation (and document this). Do refactor Do use sensible function and variable names Do keep your documentation up to date.
Never to a quick fix “because the software is basically finished”. Never think software is finished.
I have customers who ask “When will the software be finished?”. I have more experienced customers who ask “When will the software be ready to use?”.
Having been writing software since the days of the Motorola M6800 (Motorola’s first microprocessor, programmed in assembly language) I have completed many contracts. As a business I have to also ask “When can we invoice for the software we have written?”. But I can’t think of many software projects that were genuinely “finished”.
Software seems to come to an end when either
a) The use for the system the software is running on disappears. b) The development of the software has become so tangled and uncontrolled that it is no longer maintainable or useful.
If you take case a) this actually rarely means the software is “finished”. Even in those early 100% assembly code projects that I did later versions of Motorola microprocessors were assembly code compatible with earlier versions (most successful being the upgrade from the M6800 to the M6809 family). Even assembly language that is not of the same family can often be manually ported across to a different CPU if it was originally well written and well commented.
The key to good software is that it must be easy to re-use. You will find it very hard to stay in business if you try to write everything from scratch. If this goal can be achieved then case a) above becomes suprisingly rare. Trying to think of an example where an actual system disappears completely is hard. Perhaps, if the oil runs out and we can’t get any fuel for any internal combustion engine then all the engine management software out there might genuinely be “finished”…..
So that means that case b) is the most common reason for software being “finished”. Case b) must be avoidable in all cases (provided there is awareness of the need to avoid it).
If you try to open this page you get automatically re-directed to https://blogs.embarcadero.com/ which is an Embarcadero authored page of useful postings with no opportunity for users to ask questions for other users to answer (in other words it is not a forum).
So where should Embarcadero C++ users go to ask questions?
Embarcadero’s answer seems to be “Stackoverflow”
As an MVP we were warned that this change may happen. I strongly discouraged Embarcadero from going in this direction, indicating that they would lose a channel that provides good feedback for them as to how well their products are performing and also provides a chance for them to demonstrate their level of technical support.
Strange: I don’t mention open source very often and now we have two blogs in a row about Embarcadero making items open source. Delphi Bold was a Delphi experiment with the Model Driven Architecture approach to programming.
Embarcadero discontinued the development of this a long time ago, but have now decided to allow access to the source code for the open source community. It will be interesting to see if anyone picks this up and runs with it! More information at the following link
This is an interesting development. It shows that the company is aware of the open source route and is actively testing how open source can “fit” in their business model. Dev C++ (at least as it currently stands) is based around the Mingw (windows port of Gnu C++ ) compiler. (Remember the main Embarcadero RAD Studio product is based on the clang C++ compiler family).
As well as very recently releasing RAD Studio 10.4.1 (see previous post) Embarcadero have launched their #DesktopFirst summit.
Embarcadero are very wise to be promoting desktop design in this way. It’s a subject that is still of vital importance and has lost a bit of public (and developer’s !) focus recently.
I’m pleased to say that I will be making a short presentation as part of this event. With the title “Right Click is Right !” I will be suggesting that the orginal Windows approach to applications design (do you remember Windows 95? or earlier?) has a lot going for it.
Click here to join the summit. It will be a fascinating experience !