Posted by jpluimers on 2017/01/03
Is it funny because it so true? Would it be funnier if it weren’t true?
[WayBack] Technical Debt – Dilbert Comic Strip on 2017-01-03 | Dilbert by Scott Adams
–jeroen
Posted in Development, Fun, Technical Debt | Leave a Comment »
Posted by jpluimers on 2013/12/29
Thanks Uncle Bob Martin for posting this.
I’ve been trying (with increasing success: it takes time to get this all right) to practice XP (through various name changes) as much and wide as possible since almost 14 years, and only the last few years it is starting to be common practice for many more people.
take a moment to reflect back on 1999. A time when Kent Beck wrote a ground-breaking book. A book that changed everything. Look back and remember: Extreme Programming; and recognize it as the core of what we, today, simply think of as:
Good Software Practice.
–jeroen
via: Extreme Programming, a Reflection | 8th Light.
Posted in .NET, Agile, Continuous Integration, Delphi, Design Patterns, Development, Software Development, Source Code Management, Technical Debt, Testing, Unit Testing | Leave a Comment »
Posted by jpluimers on 2013/08/06
I was called by a client that didn’t want to do maintenance on an old Delphi application, but wanted to get dir of an I/O Error 131:
I/O Error 131: ERROR_NEGATIVE_SEEK
MessageText: An attempt was made to move the file pointer before the beginning of the file.
Tough luck: psychic powers told me someone is using an unsigned 32-bit integer to access a file using traditional style Assign/Reset/Seek/Read/Close patterns that Delphi kept as intrinsic routines for Turbo Pascal backward compatibility, and that file has grown over 2 gigabyte in size.
I quickly found an import file had grown over the 2 gigabyte, so this was indeed the case.
The original developers didn’t do the file access using the 64-bit Seek/Position of the TStream descendant TFileStream.
Too bad, as now someone has to dig through the mothballs to find the sources (if they survived 3 different version control system switches), create a working development environment, and fix the bug.
Another instance where technical debt in IT raises its ugly head and the compound interest is really expensive.
–jeroen
via: erikmartin.com – IO Errors in Delphi.
Posted in Conference Topics, Conferences, Delphi, Delphi 5, Development, Event, Software Development, Technical Debt | 14 Comments »
Posted by jpluimers on 2013/02/01
Yet another interesting article on Technical Debt: BBC News – Why banks are likely to face more software glitches in 2013.
Note that this is not limited to Banks. I’ve seen quite a few companies in the Financial domain, and they all suffer from it.
Even stronger: all companies I visited suffer from Technical Debt, including my own workplace, hence I created a special Technical Debt post category and tagged some previous posts with it.
It is hard to produce software without any Technical Debt, even though I try the best I can or am allowed to spend.
Therefore it is very important as a developer to be aware of Technical Debt, and help spread knowledge about it.
–jeroen
Posted in Development, Opinions, Technical Debt | Tagged: banks, bbc news, developer, financial domain, software, software glitches, spread knowledge, technology | Leave a Comment »
Posted by jpluimers on 2013/01/23
This is the first of a series of upcoming interviews on Technical Debt. Very insightful!
Ward Cunningham & Capers Jones Technical Debt Interview.
Apart from the transcript, there is also the video and the past Expert Interviews.
–jeroen
Posted in Development, Software Development, Technical Debt | Leave a Comment »
Posted by jpluimers on 2012/04/10
Lot’s of corporate environments keep killing the productivity of their software developers by running WorkPace. They claim to prevent RSI, but the main thing they do is getting you out of your mental flow.
Workpace (yes, it is written in Delphi) hooks itself into processes by injecting REC300.DLL into it.
That particular DLL prevents Delphi XE2 from installing in several of the systems colleagues tried, and gives you error messages like these:
'' is not a valid integer value
Followed by a bunch of access violations, and Process Monitor indicating issues reading the key HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\REC300.DLL which is part of WorkPace 3.0 (an old 2007 version).
The next problem was Digital Guardian (an old 2010 version) hooking itself into all processes. Uninstalling that is a pain, as it requires a special uninstall key, but luckily the automated update script on the SCCM server’s distribution share contained that in an encrypted form. Uninstalling this solved the problem.
Maybe newer versions of WorkPace and Digital Guardian wouldn’t have interfered with the Delphi XE2 install. If so, that would be another example of technical debt.
WorkPace and Digitual Guardian are most likely there because of government induced regulations in the corporate environment.
I’m feeling a bit like Dilbert now: the corporate environment is interesting, but often they make “getting work done” so much harder than it could be.
–jeroen
Posted in Delphi, Delphi XE2, Development, Opinions, Software Development, Technical Debt | Leave a Comment »
Posted by jpluimers on 2012/04/05
O'Reilly book "Unicode Explained: Internationalize Documents, Programs, and Web Sites"
Withe the growing integration between systems, and the mismatch between those that support Unicode and that do not, I find that a lot of organisations lack basic Unicode knowledge.
So lets put down a few things, that helps as a primer and gets some confusion out of the way.
Please read the article on Unicode by Joel on Software, and the book Unicode Explained. The book is from 1996, and still very valid.
Unicode started in the late 80s of last century as a 16-bit character model.
Somehow lots of people still thing Unicode is a 16-bit double-byte character set. It is not. It uses a variable width encoding for storage.
All encodings except the 32-bit ones are variable width. The UTF-16 encoding is a variable width encoding where each code point (not character!, see below why) takes one or more 16-bit words.
This is because – as of Unicode version 2.0 in 1996 – a surrogate character mechanism was introduced to be able to have more than 64k code points.
The architecture of Unicode is completely different than traditional single-byte character sets or double-byte character sets.
In Unicode, there is a distinction between code points (the mapping of the character to an actual IDs), storage/encoding (in Windows now uses UTF-16LE which includes the past used UCS-2) and leaves visual representation (glyphs/renderings) to fonts.
Unicode has over a million code points, logically divided into 17 planes, of which the Basic Multi-lingual Plane has code points that can be encoded into one 16-bit word.
There is no font that can display all Unicode code points. By original aim, the first 256 Unicode code points are identical to the ISO 8859-1 character set (which is Windows-29591, not Windows-1252!) for which most fonts can display most characters.
By now, you probably grasp that Unicode is not an easy thing to get right. And that can be hard, hence people love and hate Unicode at the same time. Maybe I should get the T-Shirt :).
One thing that complexes things, is that Unicode allows for both composite characters and ready made composites. This is one form where different sequences can be equivalent, so there can be Unicode equivalence for which you need some knowledge on Unicode Normalization (be sure to read this StackOverflow question and this article by Michael Kaplan on Unicode Normalization).
There are many Unicode encodings, of which UTF-8 and UTF-16 are the most widely used (and are variable length). UTF-32 is fixed length. All 16-bit and 32-bit encodings can have big-endian and little-endian storage and can use a Byte Order Mark (BOM) to indicate their endinaness. Not all software uses BOMs, and there are BOMs for UTF-8 and other encodings as well (for UTF-8 it is not recommended to include a BOM).
When only parts your development environment supports Unicode strings, you need to be aware of which do and which don’t. For any interface boundary between those, you need to be aware of potential data loss, and need to decide how to cope with that.
For instance, does your database use Unicode or not for character storage? (For Microsoft SQL Server: do you use CHAR/VARCHAR or NCHAR/NVARCHAR; you should aim for NVARCHAR, yes you really should, do not use text, ntext and image). What do you do while transferring Unicode and non-Unicode text to it? Ask the same questions for Web Services, configuration files, binary storage, message queueing and various other interfaces to the outside world.
The Windows API is almost exclusively Unicode (see this StackOverflow question for more details)
Let’s focus a bit on Delphi now, as that the migration towards Unicode at clients raised a few questions over the last couple of months.
One of the key questions is why there are no conversion tools that help you migrate your existing source code to fully embrace Unicode.
The short answer is: because you can’t automate the detection of intent in your codebase.
The longer answer starts with that there are tools that detect parts of your Delphi source that potentially has problems: the compiler hints, warnings and errors that brings your attention to spots that are fishy, are likely to fail, or are plain wrong.
Delphi uses the standard Windows storage format for Unicode text: UTF-16LE.
Next to that, Delphi supports conversion to and from UTF-8 en UTF-32 (in their various forms endianness).
External storage of text is best done as UTF-8 because it doesn’t have endianness, and because of easier exchange of text in ISO-8859-1.
Marco Cantu wrote a very nice whitepaper about Delphi and Unicode, and I did a Delphi Unicode talk at CodeRage 4 and posted a lot of Delphi Unicode links at StackOverflow.
A few extra notes on Delphi and Unicode:
With Delphi string types, stick to the UnicodeString (default string as of Delphi 2009) and AnsiString (default string until Delphi 2007) as their memory management is done by Delphi. WideString management is done by COM, so only use that when you really need to. Also avoid ShortString.
For any interfaces to the external world, you need to decide which ones to keep to generic string, Char, PChar and which ones to fix to AnsiChar/PAnsiChar/AnsiString(+ accompanying codepage) or fix at UnicodeChar/PUnicodeChar/UnicodeString.
Of course remnants from the past will catch up with you: if you have Technical Debt on the past where characters were bytes, and you abused Char/PChar/array-of-char/etc you need to fix that, and use the Byte/PByte/TByteArray/PByteArray. It can be costly to pay the accrued debt on that.
–jeroen
PS:
Posted in .NET, C#, Delphi, Development, EBCDIC, Encoding, ISO-8859, Software Development, Technical Debt, Unicode, UTF-8 | 2 Comments »
Posted by jpluimers on 2012/04/04
Thanks to Randy Glasbergen for the debt image
I love this quote from Jeff Attwood on technical debt in 2009:
periodically pay down your technical debt
and the Computer Weekely article about half a year ago:
Short-term speed may come at the price of long-term delays and cost.
Lately, I find that I need to explain Debt in relation to IT and Software Development more and more often.
We now all know what happens with the financial system when we let debt get out of control.
The same holds for your IT and Software Development.
Debts get introduced by not “playing by the rules”. The quotes are there because you can not always play nicely, and the rules are not always clear or known.
Lets give a few examples of rules that – from experience at clients – are more often than not neglected. The examples are based on Windows, but could just as easily be Mac OS X, Unix, OS/400 or anything else.
These few were examples ranged from technically very broad to specific. There are more, but these will give you a rough idea how wide the field of debt can be. Even debt outside the realm of Technical Debt can turn out to be really expensive.
Every time you postpone or skip a Windows version, you collect some debt in the hope (often wrongfully called expectation) that you earn more on the money/resource you just didn’t invest and putting that money/resource to use otherwise. The same holds for any other kind of debt.
The main problem with debt is not the total of the debt, it is the interest rate that makes the accrued debt grows faster than most people and organizations realize.
This is actually one of the main causes of the current world wide financial crisis, the same holds for many IT debts.
And for all kinds of debts, you often don’t know how high the interest rate will be, so the accrued value can be way beyond what you expect.
I’ve regularly seen projects collecting so much debt, that migration costs raised to thousands of hours because of it, resulting into management taking another very bad decision: rewriting the stuff from scratch. Don’t do that: Joel on Software excellently describes what happens when you do that.
What to do about it?
You might say “don’t collect debt”, but you can’t always avoid debt.
So you need to build periods where you pay off accrued debt. And you need to do that regularly, in order to avoid the interest pitfall.
This does not limit itself to software development (though that’s what I normally focus at). It covers a wide range of IT topics.
Sometimes, you can even pay your debt in advance. For instance, I was among the first to switch from Windows XP to the x64 of Windows Vista. I knew it would cause pain, but it immediately payed back by being able to use much more memory, and run more Virtual Machines at the same time. That made me more flexible and productive.
–jeroen
via: Coding Horror: Paying Down Your Technical Debt.
Posted in *nix, .NET, Delphi, Development, Opinions, Power User, Software Development, Technical Debt, Windows, Windows 7, Windows 8, Windows Vista, Windows XP | 9 Comments »
The Wiert Corner - irregular stream of stuff 