✡ I have been thinking a lot about leanness & productivity both on the staffing side and on the technology side. How do you get that super cool content driven website up quickly with all the features you want and not have it cost a fortune? One of the first things I think about is how organizational issues have direct consequences in the technical realm.
Let’s look at it in reverse: how do you find yourself in the position of having a site that costs vastly more than it earns? First we should look at some math:
- unique/month 500,000
- TCO/month 300,000$
- average revenue/unique .1$
- cost per unique: .60$
- revenue: 50,000$
- Profit: -250,000$
These numbers are pulled from a sampling of various statistics on the internet along with my experiences in TCO modeling and my experience with real costs. A rough survey of ad revenue sites will show you: it is hard out there!
In my ponderings, there are 5 components to (mis)management of a site that contribute to situation.
1> lack of a simple, powerful and inviolate core model
Can you imagine an OO project today without a clear domain model? It is kind of simple right? Start with a base class of article and then subclass the heck out of it for multiple types. Author information is in a related object, images are objects with multiple relationships, publishing rules are either attributes on the article or if they are complex enough another related object. I might be oversimplifying (a little!), but I just outlined a CMS with +/- 5 objects. Of course we might need a couple more for a taxonomy and maybe security. Not much else though.
As the project progresses and changes are requested via features or otherwise the near purity of the heart of the model should barely be touched. A development leaders should give major scrutiny to a situation where there is domain object proliferation. That brings me to…
2> lack of code reviews
What can I say here? Are you doing them or not? If you are doing them, then you wouldn’t have simple code errors, object proliferation, cache troubles, etc… that lead to a situation where a site that delivers text and images needs expensive resources to operate. Why would code reviews be skipped? Well they are annoying! You have to read all the code, sit with the developers, give her tips, correct his mistakes and be a bit of a cheerleader for a team that might be losing! This is where the next two come into play.
3> lack of technical leadership
I have no idea where I heard this first, but I often notice a “fish rots from the head.” When a dev lead isn’t doing what she needs to do to make the project technically sound; mentor and grow his staff, communicate with her stakeholders, conduct code reviews, documenting the architecture, suggesting improvements to reduce technical debt, and all the other million things it takes to be a good dev lead, you have to look at the dev lead’s leader. Why is he not mentoring the lead into this type of behavior? Perhaps he doesn’t know how to, doesn’t want to, doesn’t value quality, or might just be lazy, who knows! The point is that you then have to look up the food chain. Why is the dev lead’s leader’s leader not leading? At this level of extrapolation it is hard to even begin to guess. There is one thing that is clear; the dev lead should be able to stand up and state clearly that she would like to improve quality and articulate the issues – call it managing upward if you will. Sometimes our bosses just don’t get it, so we need to help them get it!
4> lack of real performance reviews
This is a real bummer, if you have no real reviews with real reward and consequences there is no feedback system to help mentor the teams into the correct behavior. If no matter the behavior and productivity (measured broadly not in line of code) everyone gets the same “feel good” raise what are you really doing to your staff and the project?
A suggestion: when interviewing ask a lot of questions around this topic. It doesn’t have to be 50k bonuses like in finance, but there needs to be a means by which it is clear how you will earn that next raise, promotion, title, cookie, free cruise or whatever the system might be.
I am at pains to point out that if you have issues around 3, above, this point is really moot. If your leadership is not willing to correct course a review is just another conversation.
5> an overly ridged or lose adherence to a plan or method
It is really all about moderation. Know when to make the iteration one day longer, let the team go home early, have an extra review, or whatever “violation” of the religion you might fear, but you and the team think will improve the product, work environment and overall satisfaction.
I am sure if I thought about it I could write on and on about this. I have worked in a variety of different configurations with wild successes and wild failures. But the worst of them all is a slow failure that sucks the success right out of the project. If you work on one of those, think about these 5 and see how you can contribute to positive change.