Der Flaschenhals in der Softwareentwicklung war nie das Programmieren, sondern das Verstehen des Problems. Über den unterschätzten ROI von Verständnis.
So wie ich test driven development erlebt habe ging es darum die Tests vor der Implementation zu entwickeln - das hatte nichts mit unsolidem Konzept zu tun. Das war bei Programmierern eher ungeliebt weil das Gegenteil erforderlich war: Sie muessten sich darueber Gedanken machen wie der Code aussehen soll bevor sie den taetsaechlichen Code schreiben um dafuer sinnvolle Tests zu bauen. Das wurde oft als “das sollten doch Architekten machen” gesehen, “ich leg einfach los und das wird dann irgendwann”.
So wie ich test driven development erlebt habe ging es darum die Tests vor der Implementation zu entwickeln - das hatte nichts mit unsolidem Konzept zu tun. Das war bei Programmierern eher ungeliebt weil das Gegenteil erforderlich war: Sie muessten sich darueber Gedanken machen wie der Code aussehen soll bevor sie den taetsaechlichen Code schreiben um dafuer sinnvolle Tests zu bauen. Das wurde oft als “das sollten doch Architekten machen” gesehen, “ich leg einfach los und das wird dann irgendwann”.