Archive for the ‘CodeCompany’ Category

Technology Debt

4 Comments »

If I hat to pick the one term that causes confusion in code companies, it would be “technology debt.” This metaphor, was coined at least three years ago: “Technology debt is basically when you ‘borrow’ time to avoid having to pay it now – but likely having to pay it later, generally with interest.” (Dharmesh Shah) [Development Short-Cuts Are Not Free] Compared to financial debt, technology debt is less tangible. Some don’t even think the metaphor to be very strong: “unlike real debt there is no external requirement to pay this back.” (Kendall Miller) [Technology Debt?] However I think that Kendall, as many others, is confused. This confusion might be due to the ingrained misconceptions that code mainly has functional-properties, and that each functional-property is implemented as a monolithic block of code. First and foremost, technology debt is mainly about the nonfunctional-properties, like re-usability, maintainability, robustness, security, user-friendliness, (source) controllability, compatibility, extendability, copy-n-past-level, correctness, and so on and on and on. If—as Kendall Miller seems to—one assumes code has mainly functional properties, technological debt translates into limited functionality. Functionality is like taste, “you don’t have to lay an egg to know if it tastes good.” (Pauline Kael) But if you don’t care what the kitchen looks like after making omelets, I want to be your maid nor cook. messy-kitchen-1 So two functionally-similar blocks of code have a similar technology deficit, so clearly one should pick the cheapest. This assumption gets you a techy techie, because, most every time a techie brings up non-functional technology debt, in what ever form, they are perceived as non-supportive, inflexible, uncommitted or worse. Understanding technology debt is difficult, but important. Misunderstanding it, can be catastrophic.


Hard Sales

No Comments »

Source: BusinessBalls.com

Source: BusinessBalls.com

When you are a pro-programmer, you will know “Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want. It’s just never going to happen. Get over it.” (Joel Spolsky) [The Iceberg Secret, Revealed] Hence, you live by the WNA-paradigm (give them what they Want, Not what they Ask for). However, the good people over at sales live by the opposite CAR-paradigm (the Customer is Always Right). This seems contradictory, and it is. It is also a recipe for success. A successful company will utilize abstraction layers . . . you know where paradigm shifts take place. Like: connection oriented TCP, based on connectionless IP. Client orientated CAR-sales, based on system orientated WNA-development is a prerequisite for a successful company. (Did I just say “car sales?”) As an abstraction layer, sales has to provide a CAR interface to the customer, based on the WNA interface you provide.
Read the rest of this entry »