When looking to split a large application into parts, often management focuses on the technology layer, leading to UI teams, server-side logic teams, and database teams. When teams are separated along these lines, even simple changes can lead to a cross-team project taking time and budgetary approval. A smart team will optimise around this and plump for the lesser of two evils – just force the logic into whichever application they have access to. Logic everywhere in other words. This is an example of Conway’s Law in action.


In this episode, we discuss the difficulty of using “data” to justify changing development processes (like from waterfall to Agile), Bill’s recent write-up of doing lean-style development in the BigCo of IBM, and focus on some listener feedback.

Subscribe to the feed: http://feeds.feedburner.com/UnderDevPodcast

Your friends @cote and @BillHiggins


Recent podcasts

In case you haven’t noticed, I have a few new podcasts that have been chugging along nicely. If you like my past work at DrunkAndRetired (OK, it’s not officially “done,” but we sure as shit don’t do much there anymore) you’ll like these two:

Both are in iTunes (or soon will be), so you can find them there, listen to them on the web, or subscribe to the RSS feed above. Hopefully you’ll like them, and it’d be nice to hear what you think.

Three screens

Microsoft shot for consistency with Metro, putting the square interface on its tablets, phones and PCs under something it called three-screens and the cloud. Yet Microsoft was wrong to lump PC users in with device users, as it turned out neither customers nor developers wanted Metro on their PC – they hated it.

There is a notion that Metro was a failure there, which would be good to see the proof points in (low Window 8 uptake?). But, putting that footnoting aside as a distraction from interesting noodling, there’s a fun idea in there that we’ll see a lot in the coming years: do mobile devices need different UIs and UX than PCs, and Bice versa?

Three screens

The hardest thing for most first-time engineering managers is getting used to the fact that the sum of your importance is now far beyond simply the code you write or the infrastructure you design. Your job just got a lot harder, you need to balance more distractions and learn how to keep yourself out of too many critical paths. If your first answer to every problem is “I can just bang that out,” you’re probably doing it wrong. You probably have more meetings to go to, at the very least you need to have 1-1s with everyone who reports to you, ideally once a week. All of a sudden, managing your time will become one of your most critical skills.