Extreme Programming, Rapid Prototyping, Dynamic Systems Development Method

Netsense tries to work as pragmatic as possible to accomplish it’s goals: deliver on time and within budget restraints.

Why Extreme Programming?

Because it’s good for you! No, seriously. One of the problems of programming is that it is hard work: one has to work with a high level of concentration, with a lot of repetitious acts. That means one can easy make mistakes and the mistakes have impact: the program will not work correct.

To prevent that there are several solutions. Two pair of eyes to prevent mistakes is one of them. It also prevents easy solutions and workarounds to be mended later but of course forgotten because more important problems show up.

Making testing an integral part of the program is another one. This prevents the quick workarounds

Short subprojects, with clear goals and storyboards is another one. This prevents huge projects with no breakpoints, and permits quick amendings if the software is not heading the way it should be.

These are all concepts of Extreme Programming and DSDM, agile programming or whatever is fashinable at the moment.

Welcome to the ideal world of Coca Cola and Walt Disney, where everybody is happy and no-one starves.

In reality, most of the projects are understaffed, overfeatured and without a proper understanding of the pitfalls of a project, leading to time-lags, less features as promised, leading to the hiring of extra staff, leading to extra time-loss, leading to less features implemented as promised, and shortcuts in the testing, hoping that this time everybody works faultless, ending up with a product just ready before the final meeting with drinks and thrills, but at least there is something…

Let’s say we do the best we can.

Usability and Accessibility

Another concept we try to keep in mind is the usability and accessibility of the programs we write. That does not only mean that it should be possible for visually handicapped persons to use the software. It also means a clear separation between the presentation layer and the content of a program, or the view and the datamodel.

This separation will also make it a lot easier to develop for other platforms: for smartphone-apps instead of webbrowsers, for tablets instead of PC’s.

Accessibility

Usability

Source Code on Demand

Finally, most of the stuff we do will be delivered with the source code. That does not mean that the client is the owner of the source code (unless explicitely stated). It does mean that other developers can enhance the code and fix bugs, even if the original developer is not involved in the project any more.

Public Data formats, Operatings Systems, Programming languages

I prefer DataFormats which are public, with an Openrating System of which the core is public and programming languages that are not tied to a specific operating system or supplier.

Why public dataformats. preferably with sourcecode?

We see the end user as the owner of the data that are stored on the computer. A user that has his data stored in a format that is not public,
means that the information can not be retreived at will by the owner. That can have very serious consequences in the long term: software companies fade away, dataformats forgotten by the creators.
In that way data can et lost very easily. Another problem that can occur is when data get corrupted. It should not be the case that only the creator of the dataformat can repair or retrieve the data in such a case.

That is why we try to use dataformats and tools that will enable the user to manage, store and retrieve his data without interference with the original software creator. So that the user can change of software, supplier and operating systems without much trouble.

Because of that we try as much as possible to use Postgresql and Mariadb as database systems, of SVG, JPEG2000 and PNG for graphics, Mpeg4 for video, of PDF, HTML, MarkDown and Open Document for text.

We also prefer Operating Systems of which the source code is publicly available: Linux, FreeBSD, NetBSD, OpenBSD and Mac OS are some of the OS’es we use.

Why an Operating System of which the Source Code is available?

Now that nearly every desktop computer and server is connected to the Internet it is paramount that your data is well protected against hostile attacks that come from the network. An Operating System of which the core is not known, analysed and verified on its functioning outside the company that produces it, has a far greater chance to have unknown errors. The errors can then be used by evil attackers.

Why a programming language and function libraries that are not tied to one Operating System?

We do not want to enforce the customer to use a specific Operating System only because the programmer happens to use a programming language that is only available on that specific platform. If the customer prefers to use another Operating System than that should be possible.

We prefer languages that gives customers that option, like Perl, PHP, Python, Go, Flutter

We also prefer developertools to use these programming languages that avoid to choose for a specific Operating System, such as SublimeText, Visual Code Studio and Emacs.

For hardware development we use KiCad, and we prefer Beaglebone as our main development plaform. For now, until open hardware based on RISC-V becomes our platform of choice.