Services

I am a staunch believer in sufficiently designing and architecting a system before proceeding with implementation. I also realize much of software development is exploratory and for that reason it is, unfortunately, often just not possible.

With respect to architecture, I tend to be conservative in my use of external, third-party, tools and technologies. For example, I believe it is better to potentially have slower performance due to the use of a relational database, than to have to completely replace the entire back-end of an already deployed, production system because a currently popular, open source, NoSQL system ceased to be popular.

I also believe, while there are certain benefits to using open source systems, nothing can replace the benefit of having a vendor available to immediately address a bug in their product which is causing YOUR product to fail. Particularly, when your product is already deployed at client sites. Open source is nice, but when things go wrong in production do you want your in-house developers, who are probably already very busy, frantically picking through the unfamiliar code of an external package to try to figure out what happened?

Whenever possible and feasible, I believe in abstracting the interfaces to thrid-party components, whether proprietary or open source. Obviously, the objective is to localize any dependencies on external components, so that it can be replaced much more easily in the future.

As much as is reasonable, I generally try to articulate the system design through the use of UML diagrams. This is often difficult in the early stages, when the system design is fuzzy, but the fact that it is difficult probably means we're not really clear on what needs to be built. All the more reason to spend time creating models and diagrams which are easy to change, than implementing code - which is, generally, not so easy to change.

I develop primarily in C++. I have used other languages from time to time, but for large, high performance, scalable systems there just isn't a realistic alternative (except, perhaps C, but it's not object oriented).

For embedded development where there are resource constraints, and for kernel development (e.g. drivers), I obviously use C. Realistically, there's usually not really an alternative if you're writing code that runs in kernel space.

For web development, which I don't do professionally ... but the existence of this website certainly suggests I do do it unprofessionally ... I use PHP on the server side and, of course, JavaScript on the client side. In the past, I've done some Java Enterprise Edition (JEE, J2EE), but it's been quite a while. Admittedly, I liked JEE for web development. It was wonderfully well designed and engineered, and enabled much more elegant implementations than the typical hodgepodge of technologies which are usually crammed together to implement most sites.

For basic scripting and automation, I usually use Python, which I'm sure isn't much of a surprise.

There are a lot of claims on the Internet that Java is just as fast, and just as scalable as C++, these days. I'm sorry, but there is just no evidence to support such a claim. I know, from firsthand experience, that for server development Java absolutely does not come close to C++. In recent testing, a simple, functionally equivalent server written in C++ and in Java, with 30,000 active connections, the C++ version used approximately 300MB of memory, and a median CPU usage of 13%; whereas the Java version used approximately 3.7GB of memory, and a median CPU usage of 51%. Moreover, the CPU usage of the Java version was very erratic - frequently fluctuating from as low as 35% and spiking at 112%. And, finally, once the JVM allocates memory, that memory never gets released back to the OS, so if, at any point while the server is running, there is a spike which results in a temporary increase in memory usage, that memory can never be used by anything other than the JVM - unless you restart the server process (JVM) which for a server is generally NOT an acceptable solution. So, in short, NO, Java is not a viable server development language/platform ... in my opinion. And for those reasons, I have made a deliberate decision to stay with what can actually get the job done and meet the non-functional requirements of typical server systems - C++.

A surprisingly large number of software development companies, or teams, still lack basic, routine policies and procedures. Day to day work is performed in a haphazard, ad hoc manner.

Not all policies and procedures work for all teams. One must take into account the size of the team; the personalities of it's members; the objectives of the stakeholders. But, without question, the one thing that every development team should have is some level of formality in it's processes. Too much formality stifles productivity; too little results in disorganization and chaos.

I am sometimes called upon to implement team policies for such matters as coding standards; version control procedures; code reviews; documentation requirements; et cetera. I believe every team should have as a minimum, a formal, written document, usually in an internal wiki site (or some other document management system), clearly explaining the procedures which the team and it's members follow.

From time to time, I am requested to assist with some maintenance development. Not the most exciting or glamorous of tasks, but occasionally challenging and interesting, nevertheless. This has also provided me the opportunity to be exposed to a wide range of design and coding styles. And to be completely honest, there are a lot of very bad developers out there! I think, perhaps, one of the biggest problems is that too many developers are willing to compromise the quality of their work in order to meet a deadline. Yes, meeting deadlines is important, but not when it means submitting grossly inferior, unmaintainable work product!

Over the years, I have become quite adept at systematically reverse engineering pre-existing code, documenting it as I go, and generally improving the quality and clarity of it - for the benefit of the future maintainers of it, of course.

Another of my overwhelmingly consistent experiences is most systems are entirely lacking in code level documentation. There is a popular belief that well written code is the best form of documentation. That is a complete fallacy! No matter how well the code is written, it cannot tell you WHY the original developer chose a given algorithm or data structure over another; or whether a certain line of code which seems incorrect was actually deliberate, or an oversight. There's also the very real scenario of requirements changing over time, and what was an appropriate data structure to use initially, may not be appropriate any longer. Without comments and/or documentation, how is a future maintainer possibly supposed to know that was the case?

Given that, my standard approach is to use Doxygen extensively, to add source level documentation as I'm working through the code. This ensures other developers will not also have to spend the time figuring out what the code does - and more importantly: what it's supposed to do. I also make extensive use of UML class and sequence diagrams to provide a quick, easy to understand reference of the code. When I encounter something in the pre-existing code which seems questionable, I use the Doxygen @todo tag to flag it for later, further investigation.

I believe, when something is identified as being wrong, it should be fixed - maybe not immediately if there are time constraints, but it should definitely be noted and added to a list of tasks so that it is not soon forgotten (hence, the Doxygen @todo tags).

I believe one of the biggest differences between myself and most other software developers is that I tend to rely only on firsthand knowledge and experience. I rarely give much consideration to what other people say on the Internet, in the media, in publications, or any other source. There are few exceptions which I consider "reliable sources".

Occasionally, a client actually wants to know the reality of a given technology, language, library, or tool before making a commitment to use it in their product. I have observed, over the years, many developers, team leads, and project managers make decisions based solely on what they've read on forums, blogs, or worse: on commercial "news" websites that receive advertising revenue from vendors of such technologies.

I don't know if people have always been as misinformed as they are today, or if there was actually a time in human history when people could actually find reliable, factual information about products. But either way, it has been my experience that the only reliable information is that which comes from objective, firsthand experience.

In these cases, I am sometimes called upon to perform objective, real world evaluations of some given product or technology. This often consists of reviewing the available documentation; deploying the product in a controlled, lab environment; writing specific, test cases to simulate real world environments and scenarios; and reporting my findings, along with whatever source code or other artifacts where generated during the research.

For a concrete example of this type of research project, you can review the realcomp project, including the source code, which I have made publicly available on this site.