Today I have a few goodies for you. The first a well thought out response to the increasing complexity of PHP frameworks. The second, a now well known reactionary response to the evolution of software engineering and project management methodologies.
PHP has been around for quite some time. As an open source programming / scripting language that snaps into the world’s most popular open source web server, it is easy to see why it has become the world’s most popular web application platform. With its absolutely massive developer community, rich documentation and examples and tutorials abound it also happens to be one of the easiest languages to learn. With this low learning curve, you can get into PHP rapidly and start cranking out all kinds of strange things with security issues you have never even imagined. People see this problem as well as issues with repetitious code and they tend to gravitate toward application frameworks. Over time these frameworks, beloved to their users grow and grow. ”Now it can do everything!” an excited user base will chant. But what they tend to not see so well is that as these frameworks grow, their barrier to entry skyrockets. The conversations go from, “Hey you should try this tool out. Its easy and reduces the code you have to write.” to, “In order to do that you should do, this… Make use of that pattern… Oh, you’re not supposed to use it that way… ” Funkatron posed their response quite eloquently at http://funkatron.com/posts/the-microphp-manifesto.html. Are thin frameworks too much to ask? I’d say that most things start thin, but rarely remain so for long.
Application design and programming are both something I like to call creative engineering. They are both also active processes. These activities tend to appeal to a certain type of person. A person who gets excited building things. Someone who demands results. They do not write code for the satisfaction of sitting in front of a computer for days on end or for the ever fulfilling notion of growing their asses. These are a means to an end, some deterministic result. We grow up in a self driven, wholly unstructured environment where we learn how to externalize ideas, turn tasks into algorithms and really create from our own Will. Then it happens. Grow into a world where we work with other people, and we all work for someone else. The creative engineering process meets communication constraints and business expectations. Rarely does it happen that any one person can understand all three worlds of thought. In recent years we have all witnessed the world of project management and software engineering practices evolve more rapidly than ever before. The shortfalls of every step in that evolution have both helped to shape the next evolution and further soured everyone involved. I’m willing to state that I’m rather optimistic about the whole thing these days. In my opinion things are a world better than they have been in the past, and that I would do anything to keep from reliving the dark days where management and engineers were separated by an anoxic barrier of mistrust and contempt. For those with a more purist view Zed A. Shaw presents to you, an alternative project management and software engineering practices philosophy, Programming Motherfucker (http://programming-motherfucker.com/). Its both humorous and a pointed counter movement of creative engineers who are tired of elongating the process to get to their precious results. Who can blame them. While managers and executives measure the cost of development in man months, they measure it in ass growth. Who do you think is more motivated to finish a project?
