17 years of software and system projects

Over the many years of practical involvment in industry projects I've done a lot of designs and implementations, reviews, re-designs and lately also architectural re-factorings - discovering that the re-factoring approach need not be restricted to small changes. Instead - whole sub-systems and large components can be re-factored without breaking the development process based on heartbeats. Being a system architect means working on software projects frequently. Here is what I do and what I don't:

I do:

  • Architecture, Design and Implementation of software projects (systems, frameworks, large applications) in business and embedded control areas

  • Architecture reviews of exsiting projects

  • Architecture re-factoring of running systems (a macro application of micro re-factoring methods)

  • Run projects in an XP/Scrum like style

  • Mentoring of software teams.

I do NOT design something and leave the implementation as a test case for other developers.For the simple reason that the hardest (and most interesting) problems in projects frequently show up against the end of the planned development process. Without experiencing and solving those problems, an architect will never get the necessary feedback and will not improve therefor.