When my current company began reviewing its project management and software development mode, they had a particular focus on lean project management. Now, I had encountered large software development cycles before such as the Spiral model with my previous company as well as Agile/XP which I use in my individual practice (where possible). However, I had never heard of Lean Project Management, and I was wondering how it compared. So began my Internet search.
From what I’ve found, “lean” project management tends to slant towards the management side. Personally, I view this as an incomplete approach as I have seen it implemented to emphasize the business management side while not providing equal emphasis the software development side. Don’t get me wrong, if there are inefficiencies in the process of acquiring a client or making a sale, I’m all for streamlining to make things more efficient. However, the production of a product is only part of the picture. To be fully sustainable, one cannot forget product quality and maintainability. I have seen this manifested as a pressure to deliver projects as quickly as possible without considering architecture improvements, encouraging poor code management in exchange for reduced delivery time.
I see this imbalance as a source of technical debt which, if not addressed properly, will almost certainly hurt maintainability in the long run. I consider maintainability (in the form of ease of troubleshooting/fixing/enhancing) just as important to retaining clients as is delivering a project as quick as possible. The ability to fix and troubleshoot your product quickly and easily is just as important as your ability to sell and roll out.
There needs to be a balance struck between the sales pipeline and the development/support pipeline to maximize ones ability to gain and keep clients in a sustainable way. I’m always on the lookout for ways to pay down technical debt, and I’m not afraid to speak up at the appropriate time. However, I also know that paying down technical debt often takes just as much time spent getting into it, so one must be patient in pushing for change.
I take advantage of as many opportunities to refactor as I can. Several years ago, I came across Martin Fowler’s book on Refactoring, which I wish I would have found during my undergrad. The principles I find myself using the most involve reducing complex business logic into discrete functions that serve a single purpose such as encapsulating data look up from the database and collecting exposed database logic. Additionally, in absence of a testing framework for the primary language I use, I build in test wrapper functions to help with validation. In a few cases, I even take this so far as to create entire back end support utilities to view and execute validation code that proved quite useful and actually lead to the discovery of a number of bugs and inconsistencies.
I realize that there is no one size fits all to software development and that there is always something new to learn in this area, but I do think that the optimal solution should always come from a place of creative tension between business and development needs.