Project X: About the Developer
These are some of the questions I answered online at "The BeOS Journal"
The unusual GUI design interfaces involve using the best of both worlds of the GUI portion with a command line interface: both are integrated in function, and everything is possible (short of needing to type text to create something) without requiring a mouse to get there; the GUI is designed for the fastest keyboard navigation possible, with great care paid to tab order. The underlying design is meant to be maximally functional with minimal user distraction, with all visual detail created for showing useful information, with minimal functionless eye candy. The GUI design of ďProject XĒ will (as far as I can do it) allow anyone with any level of vision to use it in a productive manner; as many as 1 in 12 people have color perception abnormalities (I donít personally, but Iíve worked with many that do), and many more people than that have other visual perception problems. Thus, Iím designing the GUI to be functional in black and white, as much as possible, such that color is just an added way to communicate the same information. Usability and efficiency as well as stability are the design goals. The user interface will be as orthogonal as I can figure out how to make it, which will also result in less code writing and debugging for me.
Take Visual Studio, for example: itís a very powerful IDE, but the power is often inefficient to use due to the complexity of the interface. You need to remember either a very large number of keyboard shortcuts, or you are stuck using a mouse. When it comes to creating new variables, derived classes, methods, etc. in the class wizard, you have to navigate a rather complex dialog and you are stuck working within that dialog until youíre done, with no way of looking at something you might be interested in for a reference. If nothing else, the dialog box obscures your vision of what youíre working on, and having to enter a complicated dialog box as done by typical IDEs involves a major distraction, even if things work right.
Also, with all the IDEs Iíve seen, all generated code is inserted in an order forced by the IDE, with no way of changing it, short of editing it by hand; this defeats the point of using the code generator in the first place, since youíd hope it would make things more efficient.
Iím one of those people that reads OS source code for entertainment purposes J I have over 20 years of experience, starting with TRS-80ís with cassette tapes, and learned 6502 machine/assembly language on the Apple 2 series, and I earned my high school varsity letter via the computer club programming competitions using Apple ][eís with AppleSoft BASIC in a format that resembles extreme programming as seen today. I assisted a friend down the street that wrote Apple 2 software on writing a ProDOS disk defragmenter in the late 80ís, when people were just starting to have hard drives for their computers. I wish Apple had continued with the development of the Apple 2 series, as there was plenty of room for the processor family to grow, and the Apple 2GS was way ahead of its time in both the power of the OS for the hardware it ran on, along with the hardware itself. The 65C816 was the closest thing youíll find to a RISC processor with 23 addressing modes, though some of them were purely optimizations for dealing with 8 bit limits. However, it could work with more than 64K data with instructions without going into segmentation like the Intel processors, and could address 16 megs without a problem. Do I sound wistful about those times?
Other than that, my professional experience has been writing software for mission critical applications, in terms of the fact that time and reliability of the process were not merely important, but vital. This includes low-level experience writing for SCSI devices such as CD-ROM drives, tape drive and CD-writers for CD-ROM pre-mastering utilities working for Digital Audio Disc Corporation, as well as being part of the team that created the first mastering machine solution to creating production multiple session discs (Surely people have at least one of those in their collections, the ones where an audio player only sees the first track(s) as audio, and doesnít see other sessions, thus avoiding listening to application code). I also wrote an application to analyze CDís at a very low level for adherence to standards that first started out in Windows with heavy C++ object oriented design, and then (at the demand of the project leader) found myself having to port it to ANSI C under Linux using a multiple process design instead; thus, I have some rather interesting experience with knowing what a C++ compiler does for you and to you! The next employer had me writing software for an engine monitoring system, collecting and analyzing telemetry. My most recent employment involved writing software for controlling CNC milling machines and press brakes that arenít shut down unless they break or need repairs, and the software was designed to be that boringly reliable. Iíve been writing software in C/C++ since 1992, and have collected a lot of arrows in my back, used several different OSís and development environments and APIs, and worked both in teams as well as individually.
Iíve had offers for beta testers to help me already, but Iím not ready for that yet anyway. Iíve had more questions of why I havenít helped on other existing projects. Other than having beta testers verify ďProject XĒ works as desired (Iím confident it will be very stable, but everyone has their own idea how things should work, and anything this complex will have at least minor bugs before release, as well as likely after) I have no real desire to have others help me with the code itself, though there might be questions I might ask about doing a few things here and there. I have a clear vision of what I want to do and why I want to do it, based on personal experience and a certain amount of market research over time on BeShare, where Iíve previously logged in as coolbear; coolbear is an ancestral name Iíve used because itís a lot more likely to have fewer name collisions on the web than my legal name. For those that have suggested features in the distant past on BeShare, be assured, I have not forgotten them!
Iíve got about 30 typed pages of description of the structure of how it should work and look, as well as the threading model that goes along with it. Iíve had this on my mind for over 3 years now, and Iíve waited more than patiently for other projects to get complete enough to fill my needs, but I could wait forever if I donít do it myself. The BeOS GUI API with the requirement of having a thread for every window and the application itself makes it a non-trivial task for ensuring that things donít get created and destroyed in such a way that avoids deadlocks and crashes due to invalid pointers. However, I have a solution that guarantees windows are not created or destroyed unexpectedly, and the manner of controlling them ensures no deadlocks as a result. Hopefully, this wonít be regarded as rocket science to everyone, but just good common sense. I anticipate releasing a minimal weight document/view library with ďProject XĒ that demonstrates by real code how that works, and I think it will help quite a bit.
Yes, due to how I design and implement software, it defines ďmodularĒ by example.
ďProject XĒ is not going to be open sourced, and will be a fully commercial product with no restrictions on people reselling/redistributing their applications that link to any libraries I might distribute with it. I havenít completely decided what license to use for any external libraries I create, but it will NOT be GPL, as thatís too restrictive for anyone that wants to sell their applications commercially.
Yes, though not as a 1.0 release item. It may be a non-version add-on later on (TBD), but the IDE design takes the thought of multiple things going on simultaneously into the threading design and data structures. I see no practical reason why people couldnít watch what others are typing as they type it, and excluding the compilation of certain source files until certain conditions have been reached. It isnít rocket science!
Thatís a two-pronged question in terms of how I would give advice: I have to break it down for developers as well as end users that donít develop. Thatís because end users often donít see everything from the same viewpoint and understanding of developers, and developers are often just as blind to the other side of the coin, and everyone ends up on edge.
To new users that donít develop, please, support the developers by buying software for sale that you think youíll need or want, but in relation to part of my personal philosophy, do not tell beautiful lies to others or the developers in relation to software; tell the truth, though try to do it as tactfully as possible, to minimize hurt feelings. As an example, donít go around telling everyone, ďOh, this software is so great! I can do this and this and this, and itís just plain neat!Ē when in fact the software in question has major stability and usability flaws that render it far from useful. Software that isnít reliable is a liability, and promoting something thatís truly horrible as being great only damages everyone: other potential users and the community at large, as well as the developer of that software. It damages the community and other potential users at large because they are working in delusion, and place faith where itís unwarranted, and will soon lose faith in anything related to the community and the OS and the software and its developer. This is especially vital for software that costs money: who has bought software in the hopes it was stable, only to find they wasted time and money? Please, donít keep buying shoddy software that doesnít fit your needs, and especially donít buy software just for the sake of supporting a developer, if you honestly know you wonít even use it. I even suggest that to those that may wish to support me in my development and continuation of Project X: Iíd rather have a customer that appreciates my work for satisfying their own requirements, rather than get money as a pity purchase. If you have discovered (as a user) that you can work around the problems in the software, when you promote the software, please, explain that thereís this open manhole cover you should watch out for, and give a path around it. However, please donít stop there when you run into such a thing: do your best to decipher the simplest conditions are required to cause that software to fail, and give a detailed report to the software developer via email or the preferred method of communication (BeShare, website, etc.) along with the system configuration. Developers are human, and donít always account for all possible choices a user can make; in addition, developers are on a spectrum from beginners with no real experience, to those that are accustomed to writing mission critical applications. Stroking the ego of a developer by leaving out vital details like reproducible flaws is FAR from being beneficial, because it creates a false sense of security in their accomplishments; they think theyíve produced the eighth wonder of the world, and wonder why the world doesnít even pay it an eighth of the attention they feel it deserves, not comprehending that it doesnít work properly for the ones they would develop for.
To new developers, there are many things I strongly suggest, and they donít apply only to BeOS:
1. Learn the language(s) of choice you wish to develop in.
2. Find a need and fill it, getting feedback from potential customers before you release, to know that you are solving the right problem.
3. Learn the system limitations and how it affects your application and the users of your application. Without users, you have no reason to develop software.
4. Remember to respect users as your customers or your boss, regardless of whether you charge for your software or not. Everything else comes down to professionalism and respecting the customer.
5. Make yourself accessible to users for support and feature updates, as much as possible. At least provide a way for them to submit suggestions and report bugs; try to release bug fixes (tested, of course!) as soon as possible. These things are much more important for commercial software, as customers expect to get more service for their money than for software that is free and/or open to their modification.
6. Write proper documentation for all of your software features, as well as making the software inherently easy to use, where that depends on the nature of the application. Remember, try to make it easy for the user to use your software as you intend, but donít make it so Byzantine that they find themselves wondering how to accomplish something. Hidden, undocumented features are at least as likely to be reported as bugs when a user discovers them, so you actually may save yourself a lot of hassle if you document how and why your software works in a given manner.
7. Test your software to the limits of your system, then make a way for others to torture your software on their systems. The multithreaded nature of BeOS and GUI apps for BeOS make this even more important, in that testing is made much more difficult. Test your code on uni-processor as well as SMP machines, and test on as many speed variations as possible. Properly written and designed applications will work correctly on every system and every speed, regardless of how slow or fast the machines or the application is. Of course, if the machine isnít fast enough to do something like render live video, there are practical limits. Nonetheless, itís good to know what it can and canít do. Test your software in as small of parts as possible, before you integrate it into the larger whole. This takes more effort than testing the application all at once to setup, but itís worth it.
8. Do a test install of your software on a cleanly installed partition. The development machine is tainted, and will provide false results if youíre missing something in the installation steps.
9. Design for usability in many ways: localization, font sensitivity, appropriate icons, etc. as well as color schemes. Weigh carefully any new GUI controls you may create for a GUI application. If you are doing something new, if it varies too much from what the user has previously experienced, youíd better document how it works, and explain why itís better. Donít use assumptions about the system font size and language, or colors. Donít assume that your users have full color perception. Donít assume that graphic icons alone will convey the right meaning. Display the application status accurately, visibly disabling features that are not valid during the current state. Give meaningful error messages when something goes wrong (desirable), and try to ensure that the user canít choose to do something that can create an error message in the first place (better, but not always achievable).
10. Buy the book ďLarge-Scale C++ Software DesignĒ by John Lakos. While it shows examples in C++, the principles covered in there apply as well to any language when it comes to things such as cyclic dependencies. In fact, cyclic dependencies are far more fatal with a multithreaded application as any GUI app in BeOS will be: cyclic code is more likely to cause deadlocks and crash conditions. There are many reasons I mentioned above why this book is important to understand and use in practice.
11. Ensure that the user doesnít lose data by some flaw.
Remember that you only have one chance to make a first impression: if an application crashes or locks up before they can even see what else it might be able to do, you stand little chance of winning them over, unless the user is very patient and forgiving.
Copyright © 2004 by Jonathan B. Thompson all rights reserved
This page last modified 7:11 p.m. Eastern Time zone, January 13th, 2004