I have zero desire to know who answers the survey, because some data collected is sensitive personally identifiable information (PII). Since PII data are involved, I wanted to make sure that the data was protected, and protect the identity of the data owners. When taking the survey, you have the option to not answer a question. Giving no response to a question is just as helpful as giving an answer to a question. The survey uses a secure connection, so all responses to the survey are encrypted.

The survey results are collected into a spreadsheet, loaded into a PostgreSQL database, and an R script to process the results. Various statistical tests are executed to find relationships between the responses to the survey, and various demographic data.

Encapsulation

I like to think of encapsulation as group like attributes together in a way that makes sense. A Class is, in a sense, a template to follow when instantiating (creating) an Object. A Class defines the characteristics (attributes) and behaviors (methods) of the group of characteristics. For example, if we are designing an application that tracks personal contacts, then a Person class would look like:Continue reading Encapsulation, Inheritance, Abstraction, and Polymorphism … oh my→

Java is, in my opinion, an excellent programming language for developing applications. However, when requirements are unstructured or vague, the advantages of Java become difficult to implement. Variables (or class members) that are expected to have values are sometimes found to be null (or absent of data). When a variable is found to be absent of data, a NullPointerException (NPE) is is thrown at runtime when a operation is performed to manipulate the data. The NPE is an unchecked exception, which means that the exception is only realized at runtime, not compile-time. A developer will not know that an operation will fail until the application actually executes and the variable is found to be null.Continue reading Null Pointer Exceptions in Java – One Person’s View→

Imagine traveling to a foreign country and needing directions to your hotel. You are not fluent in the language of the country you are visiting, so you install an application on your mobile device to aid in translating your language into the country’s native language. Now you have a remedial way to take your native language and translate what you say into something that could be understood by the residents of the foreign country. This is an example of what domain specific languages are in the world of computing.Continue reading Domain Specific Language (or asking for directions in 10 different languages)→

It seems that there are some businesses that rely heavily on tacit knowledge (“Tacit knowledge,” 2013) to run their IT services. Documentation is seen as non-value added activity (“non value added activity,” 2013). When there is a problem with an application, there is usually a name associated with the application; a go-to person. This approach places a company at-risk. One of the phrases we used to use at one of my places of employment was: “What if Jim gets hit by a bus, or wins a million dollars?”. Exactly. What happens if the person with all the unspoken, undocumented, knowledge about an application (or process) is away from the office, even if it’s for a sick day? Does the business just simply wait for the return of the Oracle? Is the response to customers, “Oh, you’ll have to wait on that financial application to be fixed, Jim is away on vacation”?

If there is one thing that is certain, doing more with less mentality has killed software development. Having a developer / programmer / analyst / tester / technical writer /etc., instead of multiple people to fill each each role, diminishes the overall role the SDLC (software development life cycle) plays in software development and maintenance. It does not mater what approach or methodology you use in getting software modified, there are defined stages in how software gets changed. I must stress software modifications, because new development in most companies is dead. Once the software is developed, it is maintained. Maybe it’s me, but most of what I read today about the various development methodologies focus on new development. Maybe maintenance is implied, but I think that most company leaders see the approaches as related to new development. This is simply not the case. The SDLC applies to change within the software and its related systems, not just new development.