Manchmal fühlt sich die Fotobranche an wie ein Patient, dem seit Jahren von allen Seiten der baldige Exitus prophezeit wird. „Das Smartphone hat gewonnen“, „Niemand kauft mehr Kameras“, „Alles viel zu teuer“ – die Grabreden waren längst geschrieben. Und dann, mitten in der Trauerfeier, blinzelt der Patient kurz, setzt sich auf und fragt, ob noch Kuchen da ist. Genau das ist diese Woche passiert: Die neuesten Zahlen des Branchenverbands CIPA sind da und sie malen ein Bild, das viele nicht mehr für möglich gehalten hätten.

Zwei Jahre Wachstum: Totgesagte leben länger

Die wichtigste Nachricht zuerst: Die weltweiten Kamera-Auslieferungen sind im Jahr 2025 zum zweiten Mal in Folge gestiegen. Das gab es zuletzt 2007, in einer Zeit, als das erste iPhone das Licht der Welt erblickte und „spiegellos“ noch nach einem Vampirproblem klang. Nach Jahren des stetigen Niedergangs ist das mehr als nur ein Hoffnungsschimmer – es ist ein handfester Trend.

Besonders faszinierend ist, wer die Treiber dieses Wachstums sind. Überraschung Nummer eins: Kompaktkameras! Ja, richtig gelesen. Die kleinen Knipsen mit fest verbautem Objektiv, die als erstes Opfer des Smartphone-Siegeszugs galten, erlebten einen Anstieg der Auslieferungen um satte 30 Prozent. Offenbar gibt es eine wachsende Zahl von Menschen, die bewusst zum dedizierten Fotoapparat greifen wollen, ohne gleich das ganze Arsenal an Wechselobjektiven mitzuschleppen.

Überraschung Nummer zwei: Kameras mit kleineren Sensoren (APS-C und Micro Four Thirds) haben zugelegt, während der heilige Gral des Vollformats bei den Auslieferungen sowohl bei Kameras als auch bei Objektiven leicht nachgab. Das jahrelange Mantra „Vollformat oder nichts“ bekommt Risse. Hersteller wie Fujifilm, die konsequent auf APS-C setzen, dürften sich bestätigt fühlen. Es scheint, als ob viele Fotografen erkennen, dass ein leichteres System mit exzellenten Objektiven oft mehr wert ist als die letzten fünf Prozent Bildqualität, die man sich mit kiloschwerem Glas erkauft.

Sony: Kameras solide, aber die Sensoren sind der wahre Star

Angesichts dieser positiven Marktdaten sollte man meinen, bei den Branchenführern herrscht eitel Sonnenschein. Ein Blick in Sonys Quartalsbericht für das dritte Quartal des Geschäftsjahres 2025 (das am 31. Dezember 2025 endete) zeigt jedoch ein differenzierteres Bild. Die Sparte „Entertainment, Technology & Services“, in der die Kameras beheimatet sind, musste einen Rückgang sowohl beim Umsatz als auch beim Gewinn hinnehmen.

Doch bevor Sony-Fans jetzt die Taschentücher zücken: Der Bericht merkt explizit an, dass die Nachfrage nach Systemkameras weltweit stark ist und sich die neue Vollformatkamera Alpha 7 V hervorragend verkauft. Das Problem liegt also woanders. Viel spannender ist jedoch ein Blick auf die Sparte „Imaging & Sensing Solutions“. Hier, wo Sony seine Bildsensoren herstellt und gefühlt an die ganze Welt – inklusive der Smartphone-Konkurrenz – verkauft, explodieren die Zahlen. Umsatz und Gewinn erreichten Rekordwerte.

Mein Kommentar dazu: Das ist das schmutzige kleine Geheimnis von Sony. Während wir über die Vorzüge der neuesten Alpha-Kamera debattieren, verdient der Konzern eine goldene Nase damit, die Sensoren für die Smartphones zu liefern, die angeblich die Kameras verdrängen. Eine genialere Geschäftsstrategie kann man sich kaum ausdenken. Sony spielt auf beiden Seiten des Feldes und gewinnt immer.

Nikon kämpft mit Gegenwind und sinkenden Margen

Weniger rosig sieht es im gelben Lager aus. Nikons Quartalszahlen sind, um es freundlich auszudrücken, ernüchternd. Sowohl Umsatz als auch Gewinn im Kamerageschäft sind im Jahresvergleich gesunken. Noch besorgniserregender ist, dass Nikon seine Gewinnprognose für das Gesamtjahr drastisch nach unten korrigiert hat. Auch die prognostizierten Verkaufszahlen für Kameras und Objektive wurden reduziert.

Als Gründe nennt das Unternehmen den harten Wettbewerb, hohe Werbeausgaben, Zölle und – ganz entscheidend – eine Verschiebung im Produktmix hin zu günstigeren Modellen. Autsch. Das bedeutet: Nikon verkauft zwar Kameras, aber nicht die, mit denen sich richtig Geld verdienen lässt. Während der Gesamtmarkt wächst, scheint Nikon Schwierigkeiten zu haben, davon nennenswert zu profitieren. Zwar wird die neue digitale Kinokamera, die ZR, als Verkaufsschlager erwähnt, doch das reicht offenbar nicht, um die schwächelnden Margen im Fotobereich auszugleichen. Es zeigt sich, dass es in diesem umkämpften Markt nicht nur darum geht, gute Kameras zu bauen, sondern sie auch mit Gewinn zu verkaufen.

Was lernen wir also aus dieser Woche? Der Kameramarkt ist lebendiger und dynamischer als je zuvor. Die alten Gewissheiten bröckeln, neue Trends entstehen, und selbst die größten Namen müssen sich mächtig strecken, um am Ball zu bleiben. Für uns Fotografen sind das eigentlich gute Nachrichten: Mehr Wettbewerb, mehr Auswahl und die Erkenntnis, dass eine gute Kamera nicht zwingend einen Vollformatsensor und einen hohen fünfstelligen Preis haben muss.

(tho)

Wir entwickeln Software nicht, weil es so schön ist. Wir entwickeln sie, um fachliche Probleme zu lösen. Diese Unterscheidung klingt banal, aber sie geht in der täglichen Arbeit vieler Teams verloren. Ich beobachte seit Jahren, wie Diskussionen in Entwicklungsteams ablaufen: Es geht um Frameworks, um Architekturstile, um die neueste Technologie. Es geht darum, ob man besser auf Microservices oder auf einen Modulithen setzt, ob man dieses oder jenes Tool verwendet, ob die Code-Coverage hoch genug ist. Worüber erstaunlich selten gesprochen wird: das fachliche Problem, das die Software eigentlich lösen soll.

Das ist kein Zufall und keine Nachlässigkeit. Es ist ein strukturelles Problem unserer Branche. Wir haben uns so sehr an technische Debatten gewöhnt, dass wir gar nicht mehr merken, wie weit wir uns von der eigentlichen Aufgabe entfernt haben. Dieser Artikel ist ein Versuch, das sichtbar zu machen – und ein Plädoyer dafür, den Blick wieder auf das Wesentliche zu richten.

Der Technologie-Tunnelblick

Warum reden wir lieber über Technologie als über Fachlichkeit? Die Antwort ist unbequem, aber nachvollziehbar: Technologie ist greifbar. Sie lässt sich vergleichen, messen, bewerten. Man kann Benchmarks lesen, Dokumentationen studieren, Tutorials durcharbeiten. All das passiert in einer Welt, die Entwicklerinnen und Entwickler kennen und kontrollieren.

Fachliche Probleme sind anders. Sie sind oft vage formuliert, widersprüchlich, und sie erfordern Gespräche mit Menschen, die eine andere Sprache sprechen – nicht im linguistischen Sinne, sondern im Sinne von Denkweisen und Prioritäten. Eine Fachexpertin interessiert sich nicht dafür, ob das System auf Kubernetes läuft. Sie will wissen, ob es ihre Arbeit erleichtert. Das sind verschiedene Welten, und die Brücke zwischen ihnen zu bauen, ist anstrengend.

Hinzu kommt ein strukturelles Problem: Die Branche belohnt technische Expertise stärker als Domänenwissen. Wer sich mit der neuesten Technologie auskennt, gilt als kompetent. Wer die Fachdomäne einer Versicherung oder eines Logistikunternehmens versteht, wird selten auf Konferenzen eingeladen. Das prägt, worauf Entwicklerinnen und Entwickler ihre Energie richten. Und so entstehen Teams, die technisch auf der Höhe der Zeit sind, aber nicht wirklich verstehen, welches Problem sie lösen.

Architekturstile als Glaubensfragen

Nirgends zeigt sich der Technologie-Tunnelblick deutlicher als in der Debatte um Architekturstile. Nehmen Sie die Diskussion um Microservices versus Monolith. In den 2010er-Jahren galt es fast als Naturgesetz, dass Microservices die bessere Wahl sind. Wer einen Monolithen baute, musste sich rechtfertigen. Wer Microservices einsetzte, galt als modern.

Aber was ist eigentlich die fachliche Begründung für Microservices? Im Kern geht es darum, Teile eines Systems unabhängig voneinander entwickeln, deployen und skalieren zu können. Das ist sinnvoll, wenn unterschiedliche Teams an verschiedenen Teilen arbeiten, wenn diese Teile unterschiedliche Lebenszyklen haben, wenn sie unterschiedlich stark genutzt werden. Es ist weniger sinnvoll, wenn ein kleines Team ein überschaubares System baut, bei dem alles zusammenhängt.

Trotzdem entscheiden sich Teams für Microservices, ohne diese Fragen zu stellen. Die Entscheidung fällt nicht auf Basis der Domäne, sondern auf Basis dessen, was gerade als Best Practice gilt. Das Ergebnis sind verteilte Systeme mit all ihrer Komplexität (Netzwerkkommunikation, Eventual-Consistency, Debugging über Servicegrenzen hinweg, …), ohne dass diese Komplexität durch einen fachlichen Nutzen gerechtfertigt wäre.

Die Architektur sollte aus der Domäne folgen, nicht umgekehrt. Wenn das fachliche Problem eine klare Trennung von Verantwortlichkeiten nahelegt, können Microservices die richtige Antwort sein. Wenn das Problem überschaubar ist und die Teile eng zusammenhängen, ist ein gut strukturierter Monolith oft die bessere Wahl. Aber diese Abwägung findet zu selten statt. Stattdessen wird der Architekturstil zur Glaubensfrage, losgelöst von der Realität des Problems.

Prinzipien ohne Kontext

Ähnlich verhält es sich mit Design-Prinzipien. DRY, SOLID, Clean-Code: Diese Begriffe kennt jede Entwicklerin und jeder Entwickler. Sie werden in Büchern gelehrt, in Code-Reviews eingefordert, in Vorstellungsgesprächen abgefragt. Aber sie werden oft so behandelt, als wären sie universelle Gesetze, die immer und überall gelten.

Nehmen Sie DRY (Don’t Repeat Yourself). Das Prinzip besagt, dass jede Information im System nur einmal repräsentiert sein sollte. Das klingt einleuchtend. Duplikation führt zu Inkonsistenzen, erschwert Änderungen, erhöht die Fehleranfälligkeit. Soweit die Theorie.

In der Praxis führt die dogmatische Anwendung von DRY oft zu einem anderen Problem: falschen Abstraktionen. Zwei Stellen im Code sehen ähnlich aus, also werden sie zusammengefasst. Aber allzu oft sehen sie nur zufällig ähnlich aus, fachlich haben sie nichts miteinander zu tun. Doch nun sind sie gekoppelt, und wenn sich eine Stelle ändern muss, muss die Abstraktion angepasst werden, die auch die andere Stelle betrifft. Die vermeintliche Vereinfachung wird zur Komplexitätsfalle.

Die Frage, ob Duplikation akzeptabel ist, lässt sich nicht ohne fachlichen Kontext beantworten. Wenn zwei Codestellen dasselbe fachliche Konzept repräsentieren, sollten sie zusammengeführt werden. Wenn sie verschiedene Konzepte repräsentieren, die nur zufällig gleich implementiert sind, sollten sie getrennt bleiben. Aber diese Unterscheidung erfordert ein Verständnis der Domäne – und genau das fehlt oft.

Dasselbe gilt für SOLID, für Clean-Code-Regeln, für jedes Prinzip. Sie sind Heuristiken, keine Gesetze. Ihr Nutzen hängt vom Kontext ab. Eine Klasse mit mehr als 200 Zeilen ist nicht automatisch schlecht. Eine Methode mit drei Parametern ist nicht automatisch besser als eine mit fünf. Es kommt darauf an, was die Klasse oder Methode tut, welches fachliche Konzept sie repräsentiert, wie sie verwendet wird. Wer Prinzipien ohne Kontext anwendet, optimiert für technische Metriken statt für fachliche Klarheit.

Falscher Maßstab für Qualität

Apropos Metriken: Auch bei der Qualitätsmessung zeigt sich der Technologie-Tunnelblick. Test-Coverage ist das prominenteste Beispiel. Eine hohe Coverage gilt als Zeichen guter Qualität. Teams setzen sich Ziele: 80 Prozent, 90 Prozent, manchmal 100 Prozent. Tools visualisieren die Abdeckung, Dashboards zeigen Trends, Code-Reviews fordern Tests für jede neue Zeile.

Aber was misst Test-Coverage eigentlich? Sie misst, wie viel Code von Tests ausgeführt wird. Sie misst nicht, ob die richtigen Dinge getestet werden. Sie misst nicht, ob die Tests sinnvolle Szenarien abdecken. Und sie misst schon gar nicht, ob die Software das fachliche Problem löst.

Es ist möglich, 100 Prozent Coverage zu erreichen und trotzdem eine Software zu haben, die am Bedarf vorbeigeht. Die Tests prüfen, dass der Code macht, was er macht, aber niemand hat jemals geprüft, ob das, was er macht, auch das Richtige ist. Die Anforderungen waren missverstanden, die Domäne war nicht durchdrungen, die Gespräche mit den Fachexpertinnen und Fachexperten haben nicht stattgefunden. Der Code ist technisch einwandfrei und fachlich wertlos.

Ähnlich verhält es sich mit statischen Analysen, Linting-Regeln, Komplexitätsmetriken. Sie alle messen technische Eigenschaften des Codes. Sie können helfen, bestimmte Probleme zu vermeiden. Aber sie können nicht messen, was wirklich zählt: ob die Software das richtige Problem auf die richtige Weise löst. Wer sich auf diese Metriken verlässt, verwechselt technische Sauberkeit mit fachlicher Qualität.

Die Fachlichkeit zurückholen

Wie lässt sich der Fokus verschieben? Es gibt Ansätze, die dabei helfen können: Domain-Driven Design (DDD), Event-Storming, Domain-Storytelling & Co. Sie alle haben gemeinsam, dass sie die Fachlichkeit in den Mittelpunkt stellen. Sie fordern, dass Entwicklerinnen und Entwickler mit Fachexpertinnen und Fachexperten sprechen, dass der Code die Sprache der Domäne spricht, dass Architekturentscheidungen aus dem fachlichen Kontext abgeleitet werden.

Aber hier lauert eine Falle: Auch diese Ansätze können zum Selbstzweck werden. Ich habe kürzlich darüber geschrieben, wie Domain-Driven Design dieses Schicksal ereilt hat. Die Kernbeobachtung: DDD wurde akademisiert. Was als einfache Idee begann („verstehe die Domäne und sprich die Sprache des Business“) ist zu einem Katalog von Patterns geworden, über den Entwicklerinnen und Entwickler diskutieren, statt mit Fachexpertinnen und Fachexperten zu reden.

Das ist bezeichnend. Selbst ein Ansatz, der explizit den Fachfokus propagiert, wurde von uns als Branche in etwas Technisches verwandelt. Wir diskutieren, ob etwas ein Aggregat oder eine Entity ist, statt zu fragen, wie die Fachleute das Konzept nennen. Wir zeichnen Bounded-Context-Diagramme, statt die Grenzen aus der Domäne abzuleiten. Wir lernen die Patterns auswendig, statt die Domäne zu verstehen. Der Sog der Technologie ist so stark, dass er selbst Ansätze vereinnahmt, die gegen ihn gerichtet sind.

Die Lösung liegt nicht in neuen Methoden oder besseren Tools. Sie liegt in einer Haltungsänderung. Wir müssen akzeptieren, dass die schwierige Arbeit, also die Gespräche mit Fachexpertinnen und Fachexperten, das Ringen um Verständnis, das Aushalten von Unsicherheit, nicht durch Technik ersetzt werden kann. Wir müssen den Mut aufbringen, weniger über Frameworks zu reden und mehr über Probleme. Wir müssen uns eingestehen, dass technische Eleganz kein Wert an sich ist, wenn sie nicht im Dienst der Fachlichkeit steht.

Software als Werkzeug, nicht als Kunstwerk

Softwareentwicklung ist angewandte Problemlösung. Wir werden nicht dafür bezahlt, schönen Code zu schreiben. Wir werden dafür bezahlt, Probleme zu lösen. Das klingt banal, aber es hat weitreichende Konsequenzen.

Es bedeutet, dass die beste Architektur nicht die eleganteste ist, sondern die, die das fachliche Problem am besten adressiert. Es bedeutet, dass Prinzipien und Patterns Werkzeuge sind, keine Ziele. Es bedeutet, dass technische Schulden manchmal akzeptabel sind, wenn sie die schnellere Lösung eines dringenden fachlichen Problems ermöglichen. Es bedeutet, dass wir unseren Erfolg nicht an Coverage-Zahlen oder Clean-Code-Metriken messen sollten, sondern daran, ob die Software ihren Zweck erfüllt.

Das erfordert ein Umdenken. Es erfordert, dass wir unsere Komfortzone verlassen und uns auf das einlassen, was unbequem ist: die Kommunikation mit Menschen, die anders denken als wir. Es erfordert Demut, also die Einsicht, dass wir als Entwicklerinnen und Entwickler nicht die Expertinnen und Experten für die Domäne sind, auch wenn wir gerne so tun. Es erfordert Pragmatismus, also die Bereitschaft, technisch suboptimale Lösungen zu akzeptieren, wenn sie fachlich besser passen.

Ich plädiere nicht dafür, technische Qualität zu ignorieren. Guter Code ist wichtig. Saubere Architektur ist wichtig. Tests sind wichtig. Aber all das ist Mittel zum Zweck, nicht Selbstzweck. Wenn wir das vergessen, bauen wir technisch ausgefeilte Systeme, die niemand benötigt. Wir optimieren für Metriken, die nichts aussagen. Wir führen Debatten, die nichts bringen.

Die Frage, die wir uns in jedem Projekt, bei jeder Entscheidung stellen sollten, ist einfach: Hilft das, das fachliche Problem besser zu lösen? Wenn ja, machen wir weiter. Wenn nein, sollten wir innehalten und uns fragen, ob wir gerade der Technologie dienen oder der Fachlichkeit. Die Antwort darauf bestimmt, ob wir Softwareentwicklung als Handwerk betreiben oder als Selbstzweck.

(rme)

Billiger heizen, komfortabler heizen, oder idealerweise beides: Das gelingt mit smarter Heiztechnik. Dazu gehören nicht nur smarte Thermostate, sondern auch weitere digitale Gehilfen, wie die c’t-Redakteure Urs Mansmann und Stefan Porteck im Podcast diskutieren.

Urs berichtet von monatlichen Verbrauchsübersichten, die manche Vermieter ihren Mietern erstellen müssen – was nur kaum jemand weiß. Urs erklärt, unter welchen Bedingungen man Anspruch auf diese Abrechnungen hat und was fernauslesbare Heizkostenverteiler damit zu tun haben.

Dann geht es natürlich auch um smarte Thermostate. Wir vergleichen sechs aktuelle Modelle, beschreiben Einbau, Nutzen sowie Funkinfrastrukturen und erklären, warum Matter enttäuscht. Wir diskutieren, unter welchen Bedingungen Geofencing, Fenstersensoren und Raumthermostate funktionieren. Und wir tauschen Erfahrungen und Tipps aus.

Die Systeme und Apps stoßen an ihre Grenzen, wenn man Thermostate und Sensoren verschiedener Hersteller mischen oder aufwendige Regeln nutzen möchte. Stefans Lösung: die Smart-Home-Plattform Home Assistant. Er beschreibt, wie man smarte Thermostate integriert, sie mit beliebigen Sensoren kombiniert und die Regeln implementiert.

Zwischendurch weisen wir auf einen neuen YouTube-Kanal von heise hin: c’t Phasenlage. Dort stellen wir Energiethemen wie Photovoltaik, Solarakkus, dynamische Stromtarife, Wärmepumpen und Smart Home miteinander verzahnt dar. Der Kanal richtet sich an technikinteressierte Einsteiger und Experten und bringt – wenn Host Jörg Wirtgen es hinkriegt – alle 14 Tage ein Video:

Zu Gast im Studio: Urs Mansmann, Stefan Porteck
Host: Jörg Wirtgen
Produktion: Tobias Reimer

► Die c’t-Artikel zum Thema (Paywall):

Warum sich Smart-Home-Technik beim Heizen lohnt

Sechs smarte Heizkörperthermostate im Test

Smarte Thermostate mit Home Assistant ausreizen[Link auf

Ohne Cloud: Heizungen von Bosch, Buderus und Junkers überwachen und steuern[Link auf

Geld sparen mit monatlicher Verbrauchsübersicht für Heizung und Warmwasser

In unserem WhatsApp-Kanal sortieren Torsten und Jan aus der Chefredaktion das Geschehen in der IT-Welt, fassen das Wichtigste zusammen und werfen einen Blick auf das, was unsere Kollegen gerade so vorbereiten.

► c’t Magazin
► c’t auf Mastodon
► c’t auf Instagram
► c’t auf Facebook
► c’t auf Bluesky
► c’t auf Threads
► c’t auf Papier: überall, wo es Zeitschriften gibt!

(jow)