Spectate Swamp Desktop Search is a multi-purpose application, incidentally
not limited to (Spectate Swamp's definition of) desktop search. Spectate Swamp claims
that the application is the best application ever made, but this is obviously more
than a bit of a stretch. The application is highly problematic on almost all imaginable
layers of software engineering, starting from very low-level problems like coding
style, stretching all the way to the project management.
The program can be understood best if one looks at the functionality. The program
can search text inside one specific file, and also highlight the context. The program
can also display images and video clips. Spectate Swamp apparently uses the program
to assist with his own tasks; he apparently maintains note files with it - the application
can merge material from clipboard to note file, for example - and searches these
notes, along with email and web clippings.
Coding style: Where do we even begin? SSDS code is a mish-mash
of eye-straining ignorance of all good programming conventions. SS uses variable
names that are not at all obvious, even based on context. (Examples: SSS, tt1 or
tot_s1.) The comments are frequently not particularly helpful either; most of the
commenting just comments out blocks of code or marks when the particular feature
was changed (of which more later). Some of the comments are completely undecipherable
and they don't explain what the code actually does in any meaningful way. (Example:
code line: ttt = "RRR", comment: "testing only re the close of the file etc...").
The code also includes several passages that are, apparently, copied from examples
as is; these are usually easily identified as they usually have meaningful variable
names.
One point is that the code is riddled with one odd idiom: using Left(buf,bufLen)
= "magic string" string comparisons. Not only are bufLens magic numbers, enabling
bugs to creep, they're often equal to the actual length of buf, rendering the comparison
equivalent to buf = "magic string".
SpectateSwamp is also blissfully unaware of the Boolean datatype, or dislikes it
for some reason; to store yes/no values he uses actual strings "YES" and "NO" (although
sometimes it's "Y" and "N", with no discernible pattern).
Architectural choices: The program goes against all conventions
of modern software design, which encourages breaking the program in modules - generally,
the smaller the better. The bulk of the SSDS program is in a massive text2_Chg()
subroutine, and all program flow within is managed through goto commands. While
goto commands were the norm in old Basic dialects, they are severely discouraged
in new, structured Basic dialects such as Visual Basic. SS makes this even worse
by using deliberately obscure labels: Modern Basic dialects do not use line numbers,
and instead allow the programmer to use arbitrary goto labels, so SS brings back
the line numbers by using labels like "line_20". In his statements, SS has vehemently
defended this spaghetti coding.
User requirements, expanding possibilities, and definition of the problem the
application is trying to solve: SS claims SSDS is a "desktop search"
application. However, SSDS qualifies as "desktop search" only in SS's own definition
and when using SS's own computer usage patterns; it does not qualify as a "desktop
search" application in any other definition of the term. In most definitions, a
"desktop search" system indexes the user's personal files, extracts metadata from
the files, and allows the user to perform searches on this metadata; for example,
"songs by a composer called John" or "instant messaging conversations that mention
pizza" or "email about Project X". SSDS, on the other hand, requires the user to
convert all data to plain text format, thus losing all formatting and metadata,
and merge everything in one file. For certain operations, the user is required to
maintain such index themselves. Further, ordinary desktop search systems allow the
user to see all metadata, such as "this matching song is 4:33 long" or "the last
pizza conversation took place yesterday" or "the boss mailed to you about Project
X using Microsoft LookOut, the bastard"; SSDS only allows you to see matching likes
in SSDS index file. For example, if you search for "Project X", it is difficult
to see when, by who, and (for example) with what program the e-mail was sent with.
At best, SSDS is a simplistic linear search application that attempts to match search
terms against a text file - and with extra features that allows the user to show
images and videos, also in random order.
SS also seems to completely ignore the definitions in question.
User interface design: SSDS has been designed to mimic - badly
- the command line environments. The user enters abbreviated commands, and results
are displayed in text format in the main window. This completely ignores all features
VB has for building simple, intuitive and modern graphical user interfaces.
It is not even a good command line environment. All commands are entered through
Visual Basic pop-ups, with little intelligent parsing done. The commands are cryptic,
and often chosen based on SS's ideas of "speed", and thus grouped together. For
example, the "SS" command starts a screen saver mode, while "TT" and "WW" are also
screen saver modes with different modes of operation. Understanding the commands
first requires the user to understand SS's logic in choosing these particular command
names. The user interface is also not in any way discoverable - the user can't be
expected to find out what the commands do by themselves or by lucky guess, and the
only way to find out what the commands do is to look at the more than occasionally
cryptic help text that does not explain the commands in sufficient detail.
Platform choice: SSDS is implemented with Visual Basic 5.0, which
is a very old version. Apparently, Visual Basic 6.0 (the last non-.NET version of
VB) cannot compile SSDS due to VB6.0's "limitations" in size of functions; however,
these "limitations" simply mean that VB6.0 is pickier about coding style, and properly
engineered applications would not run into these limits in first place. The choice
of Visual Basic also limits the possibilities of the "open source" development that
SS wanted, because Visual Basic is a proprietary language and not widely used in
open source community.
SS also claims SSDS is a multimedia player, and it can indeed play video files.
However, it uses the Media Control Interface, part of the Windows Multimedia API to do the actual
heavy lifting. Implementing a media player is a relatively simple and straightforward
matter using the APIs in question, and it is unlikely this feature alone
is a selling point. It also makes porting difficult to other operating systems.
Source control and distribution: SSDS does not use any form of
source revision control. In most software development projects, source control is
used to maintain revision histories of files; it is useful to document all changes
to the system, access past versions and to roll back mistakes. It also makes distributed
development by several developers easier, as it makes sure all conflict situations
are detected properly - if two people change the file at the same time, the system
detects it.
Instead of source control, SS relies on commenting out unnecessary code, and using
comments that have dates on them to explain when the specific code line was added.
While this is a natural thing to do in absence of source control in situations the
programmer also wants to retain old code and remember when the feature was added,
it is a bad idea from maintainability point of view: it adds unnecessary clutter
to the code and makes it hard to follow.
Further, the development project itself isn't packaged in any way. It is a norm
in Visual Basic development to use project files which store all of the relevant
non-code information about the application (form designs, build options, executable
information, etc), but apparently SS is only distributing the actual source code,
as "source.txt", and distributed a
video that shows how to set up the VB project and form controls. The process
is cumbersome in itself, and there is no indication of whether or not SS also follows
this method himself.
Development management: SS seemed to be very enthusiastic about
getting people to develop the application in "open source" style. However, he later
dismissed it all after doing development following the usual open source conventions
became too difficult for him to handle. Following the suggestions of other people,
he set up a project on SourceForge.net,
but failed to do anything else on it. Development at SourceForge.net requires, at
minimum, that the project manager - by default, the person who registered the project
- adds other would-be developers to the project and allows them to check in source
revisions. He could have even added another user as a project manager to handle
that aspect for him, requiring absolutely no other work from him. Instead, he ignored
all requests to help, even from one TDWTF user who volunteered for management.
Communication and documentation: Modern software engineering relies
heavily on proper documentation, all the way from design documents to end-user documentation.
Source code should be appropriately commented, which allows comprehensive documentation
to be built automatically, and other design choices should be documented extensively.
There are several diagramming methods and practices (such as UML) to further allow
easy explanation of the higher-level structure of the program. While it is understandable
that individual developers - such as SS - do not use such extensive documentation
for projects of their own design, SS seems to particularly eschew such documentation,
even if it would help others to understand the system. Even his attempts seem to
have failed. He seems to believe the source and flowcharts of highlight logic he
has made is all that is needed to describe the program. However, the flowcharts,
like the program itself, are very cryptic and do not help to explain the logic and
design choices used in the program.
Credit: WWWWolf -- TDWTF, Spectre -- TDWTF
The actual source code that this article refers to can be found online on Doug Pederson's website.