Forums
If the name Colins A. Bradley doesn't ring a bell for you, then the application named Payback might. It's an ironically-named accounting system that has been the subject matter of at least three posts:
It's a bit difficult to summarize, so, short of reading the above posts, you can pretty much gauge the quality of the system from the following screenshot of the database tables ...
Yesterday, we learned about the latest programming paradigm, Vector Oriented Programming. Continuing that trend, I'd like to introduce the next big thing in data storage: the Column Separated Value DataBase. Discovered by Shaun, the CSVDB will do nothing short of revolutionizing the way we store, manage, and think about data ...
It's not too often that we have the opportunity to unveil the next paradigm in software development: Vector Oriented Programming (or, VOP). In addition to sounding cooler than OOP, VOP offers all the benefits of OOP and a healthy heap of flexibility. Take, for example, this method uncovered in an order entry system used within a mid-western shipping company ...
Josh Breckman worked for a company that landed a contract to develop a content management system for a fairly large government website. Much of the project involved developing a content management system so that employees would be able to build and maintain the ever-changing content for their site.
Because they already had an existing website with a lot of content, the customer wanted to take the opportunity to reorganize and upload all the content into the new site before it went live. As you might imagine, this was a fairly time consuming process. But after a few months, they had finally put all the content into the system and opened it up to the Internet.
As programmers, we have a bit of a tendency to over-architect things ...
You don't want everyone to see your price sheet PDF? Easy stuff, we just need a few tables: Users, Groups, Roles, Operations, Tasks, and so on. Then we'd need a user authentication subsystem with a maintenance interface. And then a PDF-management database to allow users to upload and view docum ---- oh, you mean you just want to password-protect the sheet?
I have a policy that I try follow regarding duplicate concepts: I'll only post the concept again if the implementation somehow outdoes the previous. You may have guessed by the title, but today's example is from one of the more complex realms of mathematics and computer science: hexadecimal. Today's example is actually the sixth post of its kind. David H's former colleague now holds the "hex" prize for using no less than 5,000 lines to convert a byte array to hexadecimal, something which could normally be done with a single line of Java code ...
In the height of the offshore-outsourcing craze, "Steve" worked for a company that had a flagship application which managed, among other things, performance-related documents about employees. With labor being so inexpensive, the company decided to rewrite the document management subsystem which was a fairly large part of the application. Testing, as it turned out, was also a bargain when sent overseas, and the company was able to save an incredible amount of money developing, testing, and deploying a major release of their application to their customers.
Although the support calls increased quite a bit after the rollout, technical support was also a bargain when bought overseas. There were two bugs, however, that seemed to plague the application. First, when users would save a document, sometimes the changes wouldn't "stick." The support team attributed this to user error and reminding users how to save correctly. The other issue was that some documents would have "mixed" data -- employees would have strange performance appraisals tacked on to their record from managers from entirely different departments. The support team attributed these problems to "random data anomalies" and manually fixed the documents.
The first time that Aaron Robinson saw a horrible hack prefaced with a light-hearted apology (or, a "hackpology"), he was understanding. C'mon, I don't think there is any one among us hasn't had to patch up a ugly bug with an equally bad kludge. The second and third time Aaron saw a hackpology, he was still understanding. C'mon, we all have had a bad streak of luck here and there. By the eleventh hackpology, Aaron realized that the original developer of the system should have just added "I'm really, really sorry" to the header of every code file. I'm not sure what number today's hackpology is, but it was uncovered when Aaron thought he'd save a few hundred megabytes/day in diskspace and disable session debugging. Whoops ...
In yesterday's post (Bitten by the Enterprise Bug), we learned how vital enterprise application are for proactive organizations leveraging collective synergy to think outside the box and formulate their key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. But of course, that's all a "high level" overview of things. Today, I'd like to dig into the code of enterprise systems a bit.
Today's example was actually submitted by a few different people over a span of a couple months and is from the data-access layer of an enterprise .NET application. For you non-enterprise developers, here's an easy way to make your applications more enterprisey: add lots and lots of constants.
Unfortunately, Aaron's team also lacked enterprise; if they had it, they sure wouldn't have built a system without any enterprise in it. Thankfully, management knew that there are plenty of consultants with plenty of enterprise. They went and hired a company that was so enterprise, it even had enterprise in its name! Finally, the system would be flowing with enterprise and, therefore, be a much better value to its users.
The first thing that had to go with the system was its platform. But why?!?, begged Aaron, we're all .NET developers! The consultants scoffed, answering that Java is an enterprise platform. Obviously, Aaron didn't know what the first "E" in J2EE stands for.
Have you ever thought what it would take for you to leave a new job after only a few days? Here's a fun story from my colleague Jake Vinson, whose co-worker of three days would have strongly answered "this."
One of the nice thing about externalizing connection strings is that it's easy to duplicate a database, duplicate the application's files, change the connection string to point to the new database, and bam, you've got a test environment.
J.M.'s company landed a contract to fix up a mid-sized university's student ID card scanning system that had just finished being rolled out. It was a few-year deployment process, first starting with the dormitories, then moving on to the copy machines, cafeteria, local businesses, and, finally, student events. Unfortunately, it hadn't been a very smooth ride, with the final straw being the original vendor giving the IT Director the choice of "2-3 card scans" or "nightly batch scan processing." The director chose to bring in another company.
At first, the system didn't seem too bad: the software was all Java and the hardware consisted of a centralized server, a handful of node servers, and serial card scanners everywhere. Well, it wasn't all Java -- the programmers couldn't seem to figure out how to use the Java serial library (according the the comments in their code) and instead decided to develop a library in C that opened the serial ports as files.
(It's Exotic Code Day, jut for all you underrepresented hardware fans)
Adam worked for one of the very few remaining managers who actually measure performance and productivity by the number of lines of code produced. It was pretty easy for the manager to get away with such a management style as his department was a small, low-profile group named the Special Hardware Projects group, and was hidden away under layers of other management inside of a behemoth software/hardware organization (we'll call them "Moon Microsystems").
Stuart's team had just finished up developing an error notification system to log and email when certain exceptions were thrown in the application. After deployment, they noticed that one of the applications was having a fair amount of trouble with database deadlocks. Stuart's team poured through the code and identified a number of places where this could be happening, patched them all up, and deployed the changes to production. But still, there were more deadlocks.
After a few more rounds of unsuccessful bug hunting, they were finally given permission to attach a trace to the database server to watch for deadlocks. Not a single deadlock appeared in the trace. The logs, however, were continuing to fill with deadlocks. Stuart nervously checked a data validation trigger and found the problem ...
Several months back, I posted the story of a certain Java coder known best for the countless hours she dedicated to developing a key module a rather important information system (see The Brillant Paula Bean). As is the life with a contractor, Paula has since moved on to bigger and better things. Fortunately (for us), Paula has found a new home at Scott's company (not so fortunate for them).
Scott was in the final development phase of a project that, for the most part, had gone surprisingly well. Sure, the deadline was tight and looming, but the end was in sight and the final few weeks seemed like it'd be a smooth ride. In fact, it seemed like the project might even be completed before the deadline.
For many more, check out the previous post from the series ... Pop-up Potpourri: Se7en Deadly Messages
Just before reaching the End of the Internet, Bart B found the file "everything.sit", which apparently contained all knowledge in the universe. Fortunately, StuffIt let's you play solitare while it takes the next 2.3 million 230 thousand years to expand the file ...
Josh was a bit nervous about working with the A-team. No, not the A-Team with Mr. T, but the highly revered team of crack coders at Josh's company that, unlike the B-team, doesn't waste time with things like architecture, design, testing, formal requirements, or any of that other jibba jabba; they just got things done. But, the fact of the matter was, the A-team as falling a bit behind schedule and needed some help with their project.
One of Josh's first tasks was a simple one -- decrease the display size of some of the embedded demonstration videos. Problem was, he couldn't find a single OBJECT or PARAMETER tag anywhere in the source code. But he did find something that he didn't quite expect: Javascript embedded in HTML embedded in a SQL query embedded in an ASP page ...
In case you've been living under a rock for the past few weeks, the paradigms have shifted once again. We no longer are in the era of simply dynamically doing things agilely on the fly. Now is the time for dynamically doing things agilely on the fly with service oriented architectures. Consider, as an example, this old and complicated method of sending an email message programmatically ...
Michelle was hired by a software company to "clean up" an ASP.NET application they have been developing/maintaining for the last three or four years. A lot of the former team members were begrudgingly forced out of their VB6 comfort zones to use new-fangled things like "Objects", so you can imagine the state of the code. There is nothing unique about the quality (or lack-there-of) of this wonderful piece of code, but it was the accompanying comments that inspired Michelle to send it and me to post it ...
Marc was recently hired at a small company whose primary source of revenue came from a C++ based web-application. One his first day, his boss gave him a thoughtful heads-up about the code in the system: the guy before Marc was a really bad coder and had unfortunately contributed to a large portion of the application. But it was all good, assured the boss, because the bad coder was gone and they were ready to move on into a new era of quality.
After a few days of learning the system and seeing the bad code in person, Marc's only consolation was the fact that he'd get to rewrite a lot of the bad code. One piece of the system -- how SQL commands were executed by writing to a file name, passing the filename to a function, then reading back a results file -- struck him as so rediculously bad he felt like he had to joke about it with his boss ...
In case you haven't gotten your fill of bad code for the week, here are a few "quickies" ...
Let's start out with this single line from Victor Bilyk, who's predecessor liked the long way of writing "true" ...
Out of all the support calls one might get, the "system is completely frozen" problem is a fairly easy one to solve: just restart all the servers involved. Of course, when you have a competent systems operations team that watches over the application and knows how to do all this stuff, this is one of the last calls you want to get: something is probably seriously wrong with the application.
Jeff Moss was the unlucky recipient of the latter type of call. In his case, both the database and web servers would completely freeze up within minutes of the popular, publicly-available web-application coming back online. After a bit of hunting, Jeff found they were simply running out of ID's ...
Today felt like a good day to share a story, so without any further ado, here's an entertaining one that was submitted anonymously ...
Working in the datacenter of a large client with many thousands of employees, you hear some strange things. On a fairly dull weekday afternoon, I was sitting working away at a bunch of KVM screens and happened to overhear the conversation of the two people working at the console next to mine.
Feb 06