When you have awesome people and less than awesome results, it is usually one of three things
- leadership (me),
- processes or
- design (in the global sense of project design patterns).
I set all three as CEO for our rewrite of Tendenci to the open source software platform for nonprofits. Thus no matter what, I take 100% of the responsibility for delays between 2009 and 2014.
To be clear, I’m pleased with the progress on Tendenci, self hosted or our hosted solutions. Basically the team kicked ass on Tendenci 5.1 and I’m proud of them. It was definitely a cumulative effort from many people, past and present, addressing an incredibly complex problem – people.
Tendenci is about people, it isn’t a shopping cart selling shirts (and shopping carts can be complex, just nothing as complex as human behavior).
Tendenci is designed to be as simple as possible, but no simpler. The “minimum viable product” of 2009 is not something our client base wanted to hear about in 2014, even if the new version of Tendenci does mobile and much more. People don’t like to go backwards from what is now called “agile” development.
Lesson 1 – if you want to get REALLY agile – only build what people fund.
Yes, only build funded modifications. (Or contributed pull requests as time is money.) It’s amazing how many people will suggest a great mod. Everyone uses the web so clearly they are experts sharing their wisdom of how it should be built. As if driving a car makes me qualified to build one. And when you say 4k for the mod suddenly the programming module they desperately need isn’t relevant and they find another way.
Why? Why charge for modifications? Priorities. It tell you what people value. And we did that very well from 2001 to 2009. Resulting in a stress tested solid product. But proprietary because 2001 was a bit too soon to start building open source web apps. We had to start over if we wanted to be open source, so I pulled the trigger.
Then I tried to simplify things a bit too much. Things got a bit too Web 2.0 with blocks and giant fonts losing all data density in the display. Upsetting our power-users and looking clunky on screen. My bad. (the good news is it is mostly fixed now.)
Why is oversimplification such a fail?
Think about your car’s dashboard and controls. Look at them when you next get in your car. Incredibly complex information, right? Vast amounts of it. Presented while you are going 70 mph. Just wow. If what is fundamentally a horse (staying with the horse/car analogy briefly) with no visual controls, has evolved to this level of complexity, then exactly how simple can you make Association Management Software? Well, it isn’t a simple problem. 20,000 users on a web application is much more complicated than a car. Or a shopping cart.
Tendenci – because humans are complex. Groups of humans are even more complex!
So why this post? I’d like to start sharing what I learned along the way. Why this is one step in a long journey. And hopefully our clients and employees and the entire open source community will benefit from it. If not, then those who prefer destruction over creating something, those who laugh at people still tilting at windmills, then they will have won and there will be written documentation of my folly.
All I can do is tell you a bit about the journey. Record it along the way. And schedule blog posts over time.
Disclaimers: For the purpose of this series of posts I make no apologies if I speak Geek or brutalize the English language with poor grammar and typos while using pseudo-code to express programming concepts, all mixed up together with abandon in horrific run-on sentences. It happens. Go read another blog if it isn’t your thing. This one is mine.
As for the database schemas – I’ll cover that in a future post…for now suffice it to say I have had to relearn the primacy of MVC is MODEL-CONTROLLER-VIEW in that order. And it takes discipline to do that with Django. More later….