If so, you can start with delivering less.
According to the ChAOS report by the Standish Group…
- 42% of implemented functionality is never used
- 18% of implemented functionality is rarely used
Which basically says that 60% of what we do is waste.
Eliminate that 60% (or at least the 42%).
If you aren’t sure where to start, I would recommend taking a look at Lean Development and the Predictability Paradox.
The Tech·Ed Webcasts have been posted here.
My webcast (Test-Driven Development with BizTalk Server 2004) is located in the Connected Systems Infrastructure webcasts.
Thanks to everyone from Microsoft who let me do the webcast and for Drew for recommending the webcast in the first place. I had a great time doing the webcast and covering a topic that is a blast to talk (and think) about.
I’ve been involved with building mutliple app-dev frameworks throughout my career and it never fails that the frameworks end up being littered with individual application-specific code or hacks for single applications that use the framework (this seems to be most prevalent in UI frameworks). After this happens multiple times, it seems like there is really no need for the framework at all because it moves from the lofty idea of being an enabler for individual applications - to being a “this is an emergency and nobody else has time to do it
It never ceases to amaze me how complicated we tend to make things. It’s mostly learned behavior or a desire to implement the latest and greatest pattern that we’ve read about. I think that over-engineering is really one of the biggest problems that our industry faces. It’s prominent with developers, but it’s also common throughout all ranks and positions in our industry.
Unfortunately, this adds up to massive amounts of waste. We write a ton of features that never get used, we come up with really cool implementations that are really hard to maintain, and we spend a lot of time worrying about how to increase the speed of our app by a few milliseconds when it’s likely that the performance is sufficient. We think we have to concurrently handle China when our app will probably never have to concurrently handle the number of people that live on our block. The entire time that we are doing this, we are likely wasting the time and money of our clients or our organizations.
The next time you’re at work take a few minutes and notice the interaction and thoughts of the development, management, and business teams. Is everyone focused on delivering value as soon as possible to their clients? Do the daily discussions revolve more around features or more around layers? Does everyone believe and think about the intended value of the system that is being worked on, or are they just focused on writing a good data access layer or a scalable middle tier?
Imagine what would happen if you did the simplest thing that could possibly work. Imagine that you implemented your application in vertical slices of business needs versus horizontal slices of technical needs. Imagine if you allowed the architecture to evolve with the code and you let the system emerge rather than spent the time upfront to diagram out every possible scenario. It all sounds so simple – but as industry we have a lot of unlearning to do.