Die neuen Standards haben die Programmiersprache C++ merklich modernisiert und teilweise ganz neue Programmierparadigmen in die Welt von C++ eingebracht. Die “grossen” Änderungen wie Variadic Templates, auto, Move-Semantik, Lambda-Ausdrücke und weitere haben für viel Diskussionsstoff gesorgt und sind dementsprechend weit herum bekannt. Nebst den Sprachfeatures hat auch die Standard-Bibliothek eine merkliche Erweiterung erfahren und viele Konzepte aus Bibliotheken wie boost wurden so Standardisiert. Nebst diesen sehr spürbaren (und teilweise auch umstrittenen) Features gibt es eine ganze Menge an kleinen-aber-feinen Spracherweiterungen die oft weniger bekannt sind oder übersehen werden.
The core capital of modern companies are their employees. This fundamental truth is even more important for companies operating in areas that require highly trained and motivated people with a high degree of initiative. It is not just software companies that fit perfectly into that scheme, but almost any engineering-driven company and many, many companies outside classical STEM fields. After all as Humphrey Watts said: “Every business is a software business”. In the article “The James Bond Package” I wrote how having someone with the skills and mentality of James Bond in your company helps a lot when solving complex problems is daily business. However getting James Bond to work for you and then be able to unlock his full potential needs a company culture that fits the modus operandi of a secret agent.
Due to his combination of skills, motivation and initiative James Bond is the perfect agile problem solver. Agile working requires empowerment of teams and individuals, self-organizing and a different mentality than classical command-and-control structures. This is not just the case for the leaders but also for the people actually solving the problems and delivering the products. To perform in such an environment it helps if each and everyone of us shares a bit of what I like to call the “James Bond Package”.
“It is really demotivating, nothing gets done here.” A complaint I heard a few times in various settings. Sometimes just as a exclamation to vent steam, sometimes with a sigh and an edge of desperation to it. Surprisingly most of the time I hear this, it is from people that I esteem as far from lazy and quite capable of actually doing and completing things. But lack of motivation can strike the best of us.
Iterate fast and often to make better products. This rings true not just when creating software but also when developing it close to or together with hardware. IoT and fully automated Industry 4.0 are currently big topics in the industry, which promotes integrated development between hardware and software even more. Unfortunately, the reality is often that software- and hardware-engineers fail to work effectively together and because of this struggle with creating awesome products.
Unpacking a fixed-size container in C++ can be tedious, and require you to fiddle around with std::get or std::tie. But not anymore, thanks to the new structured bindings introduced in C++17. Unpacking anything with a fixed size into named variables never has been easier.
Agile is successful and we know it. For years we scrum masters, agile coaches and change champions advertised and trained developers in the agile principles and the many frameworks and ideas out there. We have seen teams and individuals grow and become self-organized and empowered. It was fun but tough work. We grass-rooted ideas with the developers and helped people changing their minds about “how we work”. And it was frustrating when we hit the hard wall of culture-shifting whole organizations instead of just teams. Our teams worked well but somehow the movers and shakers of the companies needed a lot more and a different kind of attention to bring them along. Suddenly the ideas and principles we instilled so successfully into cross-functional teams of developers, testers and engineers were under harsh critique. Somehow there always seemed a someone up a higher level that did not agree with what we tried to achieve. Countless stories of trying to put scrum into action on a contract that is essentially waterfall are a strong indicator to that.
Planning poker, magic estimation, T-shirt-size estimation and even the famed #NoEstiamtes are too inaccurate - But there is a way to estimate to up to 50% more accurately by using a simple formula based on empirical measures and applied linguistics. Notice how developers use the same qualifiers for estimating workload over and over again? “It is just a minor bugfix”, “This is a huge, complex task”, “There is absolutely no way I can put an estimate on this one”. Heard this sentences or variations of it in the past? Your best estimations are lying in front of you in plain sight.
We need to be innovative! - I heard this statement or a variation of it a few times over my past in working as a software engineer. We engineers love this, as we get more time to tinker with anything we find interesting - Which is a lot. The result are often better tools or tool-chains to make our life as developers easier, but very rarely the output of such initiatives improves something tangible for the users of the product we are working on. Why? Because on these innovation days we are usually stuck together with other engineers which means that we mainly discuss engineering problems.
Good code is self-documenting - We coders love this sentence and with the standard attributes available since C++11 we are one step closer to this utopia.