##################### Culture of Complexity ##################### - Feb 20, 2009: `Python Business Rules Engine `_ Several questions on Stack Overflow indicate a fundamental confusion about dynamic languages like Python.  It's strange how people try make things way more complex than necessary. - Dec 18, 2008: `My Favorite Appliance `_ There's nothing like no power for 65+ hours when it's hovering around 17°F (-8°C) that makes you think about which electrical appliance is most important - Nov 17, 2008: `Concealing the code base -- in Python.  I think not. `_ The "how do we protect our intellectual property?" question comes up from time to time because we're using Python.  It also came up on Stack Overflow.  Here's the approach we're taking. - Nov 13, 2008: `To GUI or not to GUI, that is a question `_ We have a couple of sales demo scenarios.  Currently, they're packed into a Django "fixture" that rebuilds the database in the known configuration.  What if the sales folks need more? - Sep 24, 2008: `"The Business Analyst Lied" Or "Python To The Rescue" `_ It's not like the lied maliciously.  They got caught up in the romance of web services and totally missed the use cases where business value was created. Now we've got software that -- viewed objectively -- isn't very close to what's really useful.  What next? - Sep 04, 2008: `The Lean Architecture `_ If this project weren't serious, it would be funny. - Sep 02, 2008: `Lean Projects — Not Deficient Projects `_ A reader notes that I omitted mentioning budgeting, metrics, personnel and documentation.  True enough. Of these, three are management practices (budgeting, metrics and personnel.)  What's important is that we need to be careful not to add management junk to Agile practices.  Not all legacy management practices are actually good ideas.  Some are just legacy. We can very easily manage ourselves out of Agile. - Sep 02, 2008: `The Big Plan For Change™ -- Since it never works, what's the alternative? `_ I'm biased against :strong:`Big Plan For Change`\ ™.  It's embodied in PowerPoint presentations, project plans, farcical schedule and comical budgets.  Change could start out as a simple thing, but, for some reason, it has to start out as complex, overwhelming planning exercises.  With rooms full of consultants.  People like me. I don't think you should invest too much in a "plan for change".  I think you have to just change. - Aug 16, 2008: `The Technology Obsession `_ Hoare's Law:  Inside every big program is a small program struggling to get out.   Lott's Corollary: Less code is better; no code is best. - Jul 18, 2008: `Technology and Compromise `_ "I can't use [X] because of this small feature which I find objectionable."  I have some other places where a sensible compromise was discarded in favor of an "all-or-nothing" strategy.  I don't know why someone would take an all-or-nothing demand for the impossible.  But it does tell me how valuable the software is if they'd prefer none of it when they could have had some of it. - May 30, 2008: `My Peers Don't Get PL/SQL, What Can I Do? `_ Give up.   First, no amount of "evidence" -- like blog entries -- will change their minds.  Second, PL/SQL isn't a very good programming language. Or, rewrite things in your preferred style and quit explaining to your peers how wrong they are. - May 24, 2008: `Some "Duck Typing Can't Scale" crap-ola `_ I've run into this vague hand-wringing that lifts up "trust" among programmers.  They use the buzzword "scalability" to differentiate between a small team (where there are no trust issues) and enterprise-scale programming where "someone" doesn't "play by the rules".  What? The paranoid claim that these "others" can't be trusted, and specific defensive measures are required to protect "us" from the malfeasance of "them".  They call it defensive programming and waste endless brain calories on writing pointless junk code. It's simpler than that. - Apr 01, 2008: `POPO and GOPS - Plain Old Python Objects and Good Old Python Syntax `_ While wrestling with XML and X12 (again) I found out about the strengths of lxml and ElementTree.  I also learned something even more important about the distinction between Plain Old Python Objects and having some other object model, but keeping Good Old Python Syntax. - Feb 05, 2008: `Python's Duck Typing Not General Enough; SQL's Minimally Typed Foreign Keys Not General Enough.  Debugging Hilarity Ensues. `_ Yes, it's true.  I did get a question on how best to create an uber-meta-general-purpose many-to-many hierarchical association type.  I suggested they lay off the caffeine. - Oct 08, 2007: `SOA, Reuse and The Unmeasurable `_ I think I finally understand why SOA has only a coincident relationship with reuse. - Sep 24, 2007: `SOA: Cheaper?  Simpler? `_ Why opt for a Service-Oriented Architecture?  "Better" seems vague an unsatisfying.  "Better than..." is a start. - Aug 17, 2007: `SOA, Web Services, and Other Religious Experiences `_ A colleague dropped a line to chat about SOA.  The questions were interesting. - Jun 28, 2007: `KTLO Management `_ Another follow-up to Berkun's `ADD `__ posting.  I find the "Keeping the Lights On" school of budget control to be particularly infuriating. - Jun 19, 2007: `Methodologies we love to hate. `_ Check out Scott Berkun's book (`The Myths of Innovation `__ ) and `Blog `__ .  - Apr 03, 2007: `Business Analysis vs. Architecture `_ Business analysis documentation should be very densely packed with information. However, there are two pieces of information to which I object. - Jan 03, 2007: `Code Quality - Which Implementation is "Better"? `_ I've been asked to address the "better" question many times. Here's a scorecard for comparing two implementations. - Dec 12, 2006: `Hidden Costs of "Convenience" `_ See Sean McGrath's post "`AJAX and the hidden cost of ease of use `__ ", a reference to a more complete article in `ITWorld.com `__ . This isn't the only hidden cost in a badly thought-out architecture. - Sep 30, 2006: `Why SOA is DOA in some organizations `_ I saw this quote the other day, and my jaw dropped. "I’d rather we have better control over our own destiny than relying on someone else" Seriously, they said "reuse be damned." - Aug 20, 2006: `Meeting The Customer's Expectation (Revised) `_ A customer wants software to do [W]; it could be simple; it could be a replacement for an ultra-complex MS-Access application. In either case, large or small, the customer's expectation is often murky. Our challenge is to understand what the customer *wanted* us to sell them in the first place. Right? And where does education fit? It seems dumb to educate the customer. Shouldn't we offer the customer what they wanted? - Jul 30, 2006: `Three Arguments for Using the Hammer `_ Why use an RDBMS in place of a simple message queue? We're digging into the **Holding a Hammer** situation, and have three supporting arguments so far: **Tomorrow's Dollars Don't Exist** ™, it has **All Those Features** ™, and **It's Already Here** ™. - Jul 21, 2006: `Is it Over-Solving or Exploiting Technology? `_ `Improving-NAO `__ provides an interesting counterpoint on `Over-Solving the Problem `__ . - Jun 20, 2006: `Over-Solving the Problem or When your architect is a DBA... `_ ...everything centers on the database. Which is often A Bad Thing™. - Jun 07, 2006: `Office is Bloated, Let's Add More `_ See Information Week [`link `__ ] for a review of the new Office UI [`link `__ ]. Rather than trim Office down into usable, separate pieces, let's add a new UI. See Computer World [`link `__ ] for Frank Hayes' take on this [`link `__ ]. You can embrace the change and suffer the cost of education, or you can reject the change and suffer the cost of support. - May 22, 2006: `What was this supposed to fix? `_ See Patricia Keefe's column [`link `__ ] recently in `Information Week `__ . She reports on a `Charlotte Observer `__ story on a Tech Fiasco [`link `__ ]. - May 08, 2006: `Software Engineering doesn't fit the Standard Model `_ The June DDJ [`link `__ ] has an article by Ed Nisley that repeats a common misstatement about Software Engineering. His thesis appears to be that perhaps this misstatement doesn't or shouldn't apply to software, but it's hard to be sure. It could be irony, or it could be a repetition of the fantasy that software engineering is like "other" engineering. - Apr 07, 2006: `The Weirdness Of Change (Revised) `_ In thinking about the value of the 20-Minute Solution [`link <../C1379130032/E20060405114954.html>`__ ], the topic of business change came up. Sometimes, software developers don't create value through software; they create value through disruptive thinking. - Mar 27, 2006: `Development, Pedagogy and Hobby `_ You can engage in the practice of programming for a number of reasons. Principally it's software development. However, there's pedagogy and hobby, also. And sometimes, all three get conflated. - Feb 24, 2006: `Rat-holes of Lost Time `_ Incipient(thoughts) forces me to think about bugs in "Whose bug is it anyway?" [`link `__ ]. How can we detect the rat-hole before following it to the dead-end? - Feb 19, 2006: `Don't Pave the Cowpaths `_ See Five Reasons to Invest in Process Management (Intelligent Enterprise, March 1, 2006) [`link `__ ]. - Jan 20, 2006: `Stating the Problem `_ Some people have trouble stating the fundamental problem that their software solves. They bundle in irrelevancies of every stripe. - Jan 10, 2006: `Why Is OO So Popular? `_ See `Why is OO Programming So Popular? `__ - Oct 25, 2005: `Rolling Your Own Hashmap (performance) `_ Huge effort, but what's the value? How is this better than TreeMap? - Oct 15, 2005: `Office 12 Interface `_ Office has gotten so complex as to be about useless by ordinary people. - Oct 07, 2005: `Management Crutches `_ Who really needs to be in the loop? - Oct 07, 2005: `The Value of IT `_ Or, Why ROI is probably worthless. - Oct 04, 2005: `Rolling Your Own HashMap `_ Why roll your own HashMap to minimize entries, when you have a HashTree? - Sep 21, 2005: `What are "Requirements"? `_ Allen Holub's Column on "Requirements Gathering" is spot on. - Sep 04, 2005: `7 kinds of complexity - 7 deadly sins? `_ The match is clumsy at best. This is a coincidence without too much real meaning. - Sep 03, 2005: `Why Are Things So Complicated? - 7 Deadly Reasons? `_ Are there 7 deadly sins of Complexity? .. raw:: html Building Skills Content Management Culture of Complexity Data Structures and Algorithms Databases and Python DocBook Economics of Software Macintosh Methodology for Non-Programmers Open Source Projects Personal Web Toys Technology News Test Driven Reverse Engineering The Lure of XML Unit Testing in Python User Interface War Stories and Advice .. toctree:: E20090220060355 E20081217194711 E20081117061023 E20081113062510 E20080924082850 E20080904061525 E20080902155944 E20080902062304 E20080815211111 E20080718061030 E20080529202932 E20080524070539 E20080401060105 E20080204212458 E20071008133712 E20070924125831 E20070817175331 E20070628152000 E20070619191925 E20070402134110 E20070103063950 E20061212111929 E20060929230922 E20060820112611 E20060730124254 E20060721180111 E20060620162253 E20060607113915 E20060522141902 E20060508070618 E20060405120217 E20060327103531 E20060223203608 E20060219163357 E20060120070100 E20060109222954 E20051025101925 E20051014220645 E20051006202841 E20051006202228 E20051004062253 E20050921104854 E20050904074406 E20050903102708