There are many types of problems in software and we developers love to solve them all. However there exists a class of nefarious problems that all teams must go through and they are no fun at all, welcome to the world of Wicked Problem
A Wicked Problem is defined as a problem that could be clearly defined only by solving it or part of it.
For most problems we first understand the problem then find ways to tract it, Wicked Problems offer no such luxury.
Essentially the only way to solve such a problem is iteratively by first coming up with a tentative solution which helps you define the problem then solve it again to come up with a solution that works.
To know wether you are smack right in the middle of a problem Conklin in his book Dialogue Mapping: Building Shared Understanding of Wicked Problems shares what characterizes a wicked problem:
- The problem is not understood until after the formulation of a solution.
- Wicked problems have no stopping rule.
- Solutions to wicked problems are not right or wrong.
- Every wicked problem is essentially novel and unique.
- Every solution to a wicked problem is a ‘one shot operation.’
- Wicked problems have no given alternative solutions.
In the world of software design, non trivial projects are inherently wicked. This follows from the following facts:
- Requirements are almost certainly guaranteed to change
- Different designers can come up with different designs all of which are correct
- The design process is full of false starts
- There is no way on the onset to know if your chosen design is good enough
- A good design is usually subtly different from a bad one.
While I would wish to conclude this article with nice algorithmic solution to this class of problems, the best advice I can give is when you come across such a problem, iterate and iterate first. It’s far cheaper to correct design mistakes at design stage than when you have a full blown coded project.
Have you dealt with a wicked problem before? How did you handle it?
Guest Post by Nelson Ameyo
Hello guys. My name is Nelson and I love hacking new stuff with PHP. I have been developing PHP applications for about 4 years now. In that duration, I have learnt a lot , made some rather expensive mistakes, but most important of all, I have experienced personal growth. Back from writing poorly designed school projects for a few bucks to building scalable modular enterprise apps for the corporate scene.
One important lesson every novice developer learns is choosing your strategy wisely. For the next few paragraphs, I will be ranting passionately about my life with PHP. Take this as a chance to explore different development paradigms and tricks that will make you a guru fast.
Choosing your strategy
Sawa. If you made it to this section, it means you really want to do your thing in PHP. It is only fair for me to give you a quick guide to picking a sane strategy. You do not want to go to a fist fight with a cannon. Neither would you want to enter a gunfight with a stick. When you want to roll out a PHP application, there are 3 major avenues to take.
- The procedural (line by line) way
This is where you will write a dbconnect.php and always require it in every PHP data-enabled script you write. This approach is good for minimal tasks e.g. whipping up a simple school project or showing ur spouse how cool you are. NEVER ever roll out a ‘serious’ project this way. There are no well defined code reuse patterns for procedural programming. (I know what you are thinking. And no. Functions just wont cut it. Too many of them are messy). It is like that old t-shirt you sleep in everyday. Never wear it to work. One more gotcha with this method is it is easily accessible with very old APIs. By old I mean really old. Old APIs don’t mix well with good performance or security.
- Roll your own (RYO) kit
About 3 years back, I was at this level. I had just made my first 3 sock from doing a dbconnect.php file for some undergrads at campo. And it took me several days to roll it out. My fire for quick money was burning. Surely there was an easier way to make like two 3 socks in a day. So I export the login table to a .sql file to make sure I never have to design that ugly table again. I also throw together a few functions to connect to the DB and login a preset user. I had successfully optimized my production rate with functions, so I set a target of 2 ‘clients’ a day. But business was hard back in the day. I managed 1 ‘client’ a day and was able to reduce my wages to one chwani (150) since I was ‘mass-producing’. As more jobos came my way, I decided to offload some functions to class methods. This move made my work very easy. I could roll out user authentication in a day or so. However, I lost a majority of my ‘clients’ who could not explain the OOP concepts I had used on their projects to the tutor. They lost marks and I lost revenue. Business collapsed and I was back to eating at the cheap madondo dunga-points around campus. That was my intro to OOP concepts.
- The OOP / framework (object oriented programming) way
OOP is the best thing ever since the invention of sliced bread in 1928. It is just a bunch of amazing runtime juiciness rolled into a twenty-something MB package (linux users know this). I guess the size is bigger on Next Next Finish (Windows platform). Object oriented programming now got me from the 1 chwani developer to a ninja in a little over 8 months. This is where life got exciting. I actually got to code right, code in large teams, build apps I mostly dreamt about and sweet of all, I made good money doing it. Object oriented programming introduces several principles which are really key to entering guru paradise. These are classes, objects, polymorphism, constructors, destructors, inheritance, accessors etc. etc. I urge you not to pay attention to the fancy words. They are really simple once you get to get their vibe. Here is where I will get into frameworks. Wikipedia defines a software framework as follows:-
A software framework is a universal, reusable software environment that provides particular functionality as part of a larger platform to ease development of software apps, products and solutions.
This said, I am a very lazy coder. I TOTALLY love PHP frameworks since have been designed by other lazy coders So instead of rolling your own (RYO) framework, you can pick one of the many listed in this Mashable post.
I am an ambassador of CodeIgniter specifically because they pay attention to 2 things I value most in tech; performance and flexibility on a very memory and small memory footprint.
If you feel adventurous, you can download CodeIgniter and give it a test-run. It is very easy to learn. I personally got it in a little over 2 weeks back when it was in version 2.0 back in 2010. I have been using it ever since (now @ version 3).
OOP over functions
I have been hearing a lot of murmurs why functions are ‘awesomer’ than objects. Well, here is my very scienific take on it that will be sensible to all of you. Functions were invented to fix the issue of code reusability back in the 90s. I actually think Rasmus Ledorf was thinking functions when he wrote the PHP language. We are no longer in the 90s. We now have faster processors and better computing hardware. Requiring functions file everyday is a lil bit stressful for a daily coder. We now have cool OOP features that functions can’t just match. This doesn’t mean they are not relevant. They are very much in use today. Except they are now being used as class methods so that they can get a piece of OOP goodness just the way they are. This thread on StackOverflow is awesome at capturing this
PHP is the most popular language on the Internet
Never roll your own framework on ‘serious’ projects
Favour a framework for accelerated developemnt times