Making it lean
Programming is the most known part of software engineering to non software types. A couple of years ago I improved my skills in programming with the hope to improve my software engineering skills. But it took not very long for me to realize, that it takes a lot more to be successful in software engineering.
It's quite sad, but if you are honest even with your source code quality is far below average the project may be a success by the given business goals. On the other hand side your source code may be excellent, your code metrics are outstanding and your architecture is state of the art but you are missing the needs of your stakeholders by miles.Programming is the most known part of software engineering to non software types. A couple of years ago I improved my skills in programming with the hope to improve my software engineering skills. But it took not very long for me to realize, that it takes a lot more to be successful in software engineering.
This is quite sad to say, but if you are honest: Even with your source code quality is far below average the project may be a success by the given business goals. On the other hand side your source code may be excellent, your code metrics are outstanding and your architecture is state of the art but you are missing the needs of your stakeholders by miles.
Realizing this made me a kind of sad, because learning to be a good programmer is task you can achieve by practicing. But learning how to e a good software engineer is a lot more difficult. It's about communication, understanding the needs of your stakeholders, making good decisions, being flexible and able to incorporating short-term requirements.
In the last years I was able to learn some important lessons, which I believe, made me a better software engineer. Working on some medium to large sized software development projects from 2001 to 2009 I learned what is important and works fine but I also had the chance to make some quite big mistakes.
During the last years I read a couple of books about different software development approaches. Starring the classics from Tom DeMarco (e.g. The Deadline) which are quite excellent. My problem with the DeMarco/Lister books is, that they soon start to repeat them self.
The next great books where from the extreme programming (e.g. from Kent Beck) and agile development guys. I love this concepts. They are great! I guess anyone dealing with waterfall style processes and monster MS Project plans will agree.
One of the highlights of the last year where the books of Mary and Tom Poppendiek:
- Lean Software Development: An Agile Toolkit"
- Implementing Lean Software Development: From Concept to Cash
The Poppendieks are bearing some resemblance between agile software development and lean production methods and offering some very easy to understand principles. I am quite curious and exited how I will be able to incorporate this principles to my daily work and our organization at scoyo.
One thing I learned the hard way. No software development process will work, if your organization is not willing to accept the consequences.