Just digged up

Welcome to MolesBlog.

In my first post, I want to introduce to you, who am I and why I started this blog.

I’m a professional elelctronics engineer, never getting enough from hardware, software, IT, … everything that has to do with creativity and technology is a good candidate to attract me 😉

I started my experience around 30 years ago, when I was a child. 1987 I got a Commodore C64 and a few electronics construction kits from my uncle, including a soldering iron. This made me locking myself in the garage for weeks. I soon blew away the CIA of the so called User-Port (max output current is 2mA) of the C64 with my first clavilux LED (drawing 20mA) experiments and soon, beside going to school, I spent most of my time in my garage, sometimes together with friends having the same interrests. This was the starting point of my career, leading to a diploma degree in electronics engineering with a great emphasis on VHDL, software in general and open source in particular.

During the last years, I realised that engineering has a lot of best practices, but hardly anybody is doing it with heart and soul. Many projects, independent from the company’s industry, either rule their developers with strict processes or give them plenty of rope. Neither plenty rope, nor strictness leads to high quality software. This I encountered many times with brownfield projects I need to take as a base for my developments.

But even when I got a greenfield project (not yet happened in my business career, only with private projects), it is hard to find some guideline, how quality assurance works best and makes fun. There are too many pitfalls and time wasting hurdles to not being forced to take some shortcut, always guiding you to a messy product, lacking real software quality. This always leads to dissatisfaction. Sometimes you just skip the testing, sometimes the toolchain effectively resists to play well or at all in a continuous integration environment. This mostly applies to very expensive commercial toolchains in my experience.

The most important question seems: Who else should back the quality of software, hardware and embedded systems, if not professional developers, engineers or technology addicted people like me and possibly you? Your boss, your project manager? Most probably some (so called) quality engineer, if he/she has time or exists at all. Regarding to SCRUM (which does not define a Project Manager and a quality engineer), the responsibility for quality belongs to the development team, not anybody else. This means, YOU, the developer is totally responsible and always needs to fight against commercial demands from the product management.

Another question simply is: Does it give you satisfaction to write bad code, hunt silly bugs or getting an „enema“ from your boss because of bad quality?

Welp, would you like to be satisfied about your work? Could quality lead to this satisfaction?

From my experience in various projects, a good starting point to get satisfaction (and quality) are the following rules:

• Try to be the best in your class – You are a professional, then be one. If you order a mason, you expect he uses a mason’s level and delivers extraordinary quality. With software, customers usually don’t see „your work“, but your colleauges and yourself do. Apart from this, it is simply awkward if customers experience a lot of bugs.
• Keep yourself up-to-date – Read blogs, magazines, books and watch videos about your profession. Especially with technology, you can not expect the world keeps as it is until you retire.
• Review your work and yourself – One of the most important things is review and retrospection. Look back on your work and yourself and always ask, what could have been done better.
• Keep human 🙂 – Take advantage of not working on your own. Your teammates are also professionals and have deeper knowledge in some parts than you. Trust them, talk to them and work together to get the most out of your project and life.

These are only a few thoughs to prepare the base for being a responsible and accountable development team. BTW, SCRUM already introduces some of these concepts as a part of it’s process.

I’m happy to receive responses about my statements above and I’m also interested in topic suggestions for future posts.

In my following posts, I plan to write about the STM32 test driven development (TDD) process, I currently try to establish, using unit tests and a CI to ensure a high quality and about how it is to (try to) be a Clean Code Developer (CCD).

Best Regards,
Daniel /themole