links for 2008-09-25 September 25, 2008
-
Alex highlights how librarians misuse xml in relation to marc. There's a deeper theme that applies to xml schemas outside the library world as well that I've struggled with. Codification with angle brackets doesn't get you much apart from a feature checkbox in the product marketing. Semantics in a codified manner are a very powerful thing that reduces development time and complexity. Schema's and xml developed like this fail the fundamental test when adopting a new technology, does it make things easier and simpler?
links for 2008-09-21 September 21, 2008
-
"1987, Lawrence J. Peters, Advanced Structured Analysis and Design, Prentice-Hall, ISBN 0130131377, page 2"
First cited source for the term 'automagic', everything ever has been throught of before.
-
"What is it that gets you motivated to do your job really well? Is it the pat-on-the-back from your boss' secretary? Is it the box of candy near the coffee machine? Is it your users sending you postcards from Brazil?"
links for 2008-09-18 September 18, 2008
-
"I’ve sneering dubbed this philosophy “Rules-First Programming.” I hope by naming this demon I’ll have power over him the next time he comes to sit on my shoulder. When doing things right becomes more important than doing things at all, I hope to recognize his peculiar smell, an acrid mixture of frustration, sanctimony, cowardice. “Rules First Programming,” I will say, “you better go sit on some other fool’s shoulder today because today I am going to ship.”"
Working for a products company that ultimately perishes or prospers on shipping software I agree completely. But, breaking the rules comes with a cost in the form of technical debt, some's ok, but too much and it can break the teams back. So IMHO you need to know the rules absolutely, but you need to understand the costs they impose and the costs if you weaken or break them. Ultimately if you don't ship you won't have anything you can apply rules to, or at least get paid for it.
-
"Lying to your risk-management computer is like lying to your doctor. You just aren’t going to get the help you really need. "
links for 2008-09-17 September 17, 2008
-
"there's a far more insightful way to think about it. Apple had a monopoly on the graphical user interface for almost 10 years. That's a long time. And how are monopolies lost? Think about it. Some very good product people invent some very good products, and the company achieves a monopoly.
But after that, the product people aren't the ones that drive the company forward anymore. It's the marketing guys or the ones who expand the business into Latin America or whatever. Because what's the point of focusing on making the product even better when the only company you can take business from is yourself?
So a different group of people start to move up. And who usually ends up running the show? The sales guy. John Akers at IBM (IBM ) is the consummate example. Then one day, the monopoly expires for whatever reason. But by then the best product people have left, or they're no longer listened to. And so the company goes through this tumultuous time, and it either survives or it doesn't."
-
Great article touching on the origin of the program manager and encapsulates nicely on what I agree is wrong with the PM role, management vs leadership, that said some PM's I've come across lead and lead well. At least IMHO the future is lean or agile style, self directing groups with leaders who do. The PM role for me seems like an old school hierarchical management artifact worried about a lack of control. The development process can be and is scary, solving problems by innovation from the outside is chaos/magic. If the team can't be trusted to think about the problems and you need a role to manage/think, then you'll get an emergent division; devs who think only technically and lose sight of the core problem and management that doesn't understand what's needed to actually deliver these things and lack of judgement ability. Organisations that make money from innovation need to embrace and direct the chaos rather than seeking to manage it and 'fractal' teams are a part of that.
Daniel Harrison's Personal Blog 