Feb 2, 2011
Overview I was having lunch with my friend & colleague last week and we had a disagreement about whose decision it is to make a change when you see something wrong in the client’s software. Mechanic analogy My colleague used an analogy about a mechanic; it was a good one, so I’ll use it here. Let’s say you bring your car in for a $30 oil change, and your mechanic notices a problem with the timing belt. My colleague suggests, he doesn’t just ignore it, he tells you it’s an emergency must be changed immediately (the emphasis is my friends). Well I agree the mechanic shouldn’t just ignore it, and I was relieved my friend didn’t suggest the mechanic should simply change the timing belt, driving the bill from $30 to $930, but I’m not sure if telling the car owner they must change the timing belt ‘now’ is appropriate either. In my opinion the mechanic should tell the customer what he found, the risk in not fixing it, outline the options to fix it, and the cost & associated risk with each option. Then make a recommendation. It’s the customer’s decision, not the mechanics, and even if the customer makes a foolish decision, it’s his decision, not the mechanics. Fortunately, all the mechanics I’ve dealt with seem to understand this. As consultants we’re advisors, not the decision maker In my opinion, our role as consultants / advisors includes the responsibility to inform the client of any problems or potential problems you’ve noticed, the risks in not fixing it, options to resolve the problem, along with the costs and risks associated with each. Unethical behaviour To me it seems unethical to go rogue, and just start making changes the client doesn’t know about, and didn’t approve. It’s also unethical to purposely instil fear, uncertainty, and doubt when explaining the options to the client so they make the decision you want them to; regardless of your intentions. The client owns your time After all, the client does own the software, is responsible for its maintenance, and they do own your time to direct as necessary. Wait, what? Who owns your time? Yeah, when you’re consulting, your client (or employer) owns your time. … you sold it to them; remember? Every consulting and/or employment agreement is different, but if you’re charging by the hour, it probably says something like this; they bought your focused efforts to solve their problems for a...
Mar 25, 2010
This is post 2 from a 7 part series entitled Technical Achievements in my Last Project. My role in this project started out by being asked to assess the existing project, provide insight into options to move it forward, with one of those options being a rewrite*. An estimation was needed for the rewrite option, so I was given 2 weeks to do it. This post explains how I was able to pull off this massive estimation undertaking in a mere 2 weeks. Ideally, the project documentation from the existing system could be used to give an excellent estimate, but this is a blog post, not a fairly tale. Or a thorough specification could have derived from an in depth analysis of the existing application, which business could have adjusted as needed, and used to conclude a reasonable estimate. But this is the real world, and this is a real business; and I was given a real (short) deadline. Now I should also mention this wasn’t a 20 KLOC project, it was a fairly complex piece of software with over 500 KLOC** and almost 1800 database objects along with satellite applications. Everybody understood how this short timeframe severely limited the accuracy of anything I would be able to provide, but I was determined do the best job possible. So my next goal was to figure out how to do a somewhat accurate estimate, provided the constraints, where I wouldn’t be setting myself up for a lynching at the end of it. I explored many different ways to get a rough idea about the entire projects scope. This is what I finally settled on: Dumped all Microsoft Access Objects First I modified an Access VBA script I found for exporting objects to text files and exported everything. Dumped all database DDL I wrote a little command line utility to loop through a SQL Server database, pull the DDL for each object using the sp_helptext stored procedure, and write it out to text files. Created an analysis database Created an analysis database primarily comprised of three tables; one for all the entities the application is comprised of, a second for linking which entity called which, and the third for linking menu items to all dependent forms. Collected the names of all objects into the database I wrote another little command line utility to read each code file dumped out in steps 1 & 2, and add the objects name and a...
Mar 22, 2010
Mar 19, 2010
I have always, like so many other programmers, had a problem with software estimation and costing out a software project. Most of my career was plagued by software estimates so bad that I made significantly less money on my independent projects than I did at my low paying day jobs. This was not the reason I was working through my vacations! The turning point came when I realized the CRUD acronym encompassed most of the functionality of the line of business applications I was writing and could be used as a check list to ensure I wasn’t missing functionality. Later, this checklist was refined to CRUDLAFS. Wait! What? CRUDLAFS? … did I just coin a new acronym? …. Hmmm, looks like I did!</egosmirk> While I’m sure you are already familiar with the CRUD acronym, here is CRUDLAFS: Create All functionality around validating and creating an entity Read All functionality around reading and displaying an entity Update All functionality around validating and updating an entity Delete All functionality around deleting an entity List All functionality around querying and displaying a list of entities Additional All additional functionality related to an entity Filter All functionality around filtering a list of entities Sort All functionality around sorting a list of entities I set up an Excel spreadsheet with CRUDLAFS as column headings, all my known or probable entities down the left, and probable hours to accomplish each in the cells, like so: So in my example, the estimated time to create a list of orders is 5 hours. And when I say known or probable entities, I mean; on smaller projects, I usually have a pretty good idea what all the entities will be, but on big projects, I charge hourly until requirements, data model, GUI design / functional specifications, and initial risk assessment is complete. Most larger projects just have too much back and forth communication and the customer usually doesn’t even have more than a vague idea of what they want. This was a very important distinction which has kept me out of bankruptcy. I get the feeling this may not work well with agile approaches, but for Big Design Up Front projects, it has been a major leap for me. Copyright © John MacIntyre 2010, All rights...
Mar 8, 2010
Last week I listened to Seth Godin’s audiobook Linchpin. It really resonated with me and I had a few significant insights. One of the interesting ideas he promoted was the idea of ‘gifts’. A gift as he explains it, is any additional work above and beyond what is required as part of the ‘transaction’. The transaction is fulfilling your end of the bargain for their end of the bargain. Seth Godin explains a transaction as If I sell you something, we exchange items of value. You give me money, I give you stuff, or a service. The deal is done. We’re even. Even steven, in fact. And he explains a gift as If I give you something, or way more than you paid for, an imbalance is created. Lets say a client is having an issue and after some digging, you have an insight where a slight change not only resolves the current problem, but prevents a similar problem from occurring throughout the entire application. The client did not offer to pay for it, and you can’t charge them, as a matter of fact, if you are a consultant, it will reduce future billable work from the client to fix the future problem. The insight and change is a gift.* Seth continues with regards to the gift: That imbalance must be resolved. So how is this imbalance resolved? … Appreciation Yep … that’s it. If you have a particularly astute client/employer, you may receive additional work and referrals as a consultant, or a bonus, raise, and/or promotion as an employee, but these are peripheral. Appreciation is the critical element for the recipient to experience**. If your gifts are not appreciated, the client/employer does not value what you have to offer and both of you should seek out more compatible relationships. So why give a gift? Personally, I give gifts because I want to create the best software I am capable of creating. Creating beautiful software, not just meeting requirements, is the very nature of craftsmanship. Beautiful software is a gift. I can’t write software without gifts. I am actually repulsed by the thought of merely delivered what was asked for since the requirements are always missing something. Yes I’m repulsed. It reminds me of those Mad magazine comics; ‘If kids designed their own xmas toys’. With few exceptions, the results would be horrendous! Unfortunately, I’ve noticed a downward cycle with the reception of my software gifts. I’ve noticed when...
Dec 3, 2009
I think every time management book, article, & blog post I’ve ever read tells you to put all your work in order of importance and then work in order of importance. This is great, since the easiest / fastest stuff is always deceptively drawing you in, but never seems to end … and most of it really isn’t important to your goals. However, I don’t know about you, but my most important tasks seem to be 100+ hr sub projects, and simple 5 minute job never become the most important task, even though you can knock em down in minutes! So here’s how I attack my work now: I work on my most important task first. Then I work on the fastest & easiest tasks. Then I work on my oldest tasks. I also pay attention to the time, and never spend more than a day on the easy stuff, so I don’t spend my whole life on...
Jul 9, 2009
Some of my projects are a fixed rate and some are hourly. If the scope of the project is small enough to accurately estimate, risks are minimal, and nailing down requirements is practical, I may propose a fixed price. Working on fixed price projects are a piece of cake, I go home, work on it, provide periodic updates via email, phone, or in person. When I finish it I install it and give them a CD with all the binaries, documentation, and source code. However, I’ve found working on an hourly rate to be a little different than doing all the above while just counting my hours. There is a lot of distrust with hourly professionals which is only compounded with a mysterious process like software development. After all how do they know you aren’t home watching soap operas, working on your own projects, the project of another client, or even sitting on the beach? How can they tell they aren’t being over charged? The problem with trust, is even if you are honest, a false perception can still destroy the relationship. I know this too well. Once in the late 1990s I was working from home, charging hourly, and I got a call from one of the newer partners of my biggest client (only client at that point). While talking I rebooted to clean out my system* and when the system came back up it played the 20th Century Fox theme, a configuration change I thought was very cool, and he said ‘Are you watching TV?’ I said ‘No. Why?’ … Seriously, I didn’t even making the connection. Two days later I was called in for an unscheduled meeting where my invoices were questioned, I heard a lot of “we’re not accusing your of inflating your hours…”, and the next day, feeling insulted and unappreciated, I resigned. I didn’t make the obvious connection until much later. It doesn’t matter that I was under charging both in terms of my rate and what I charged for, and would never inflate my hours! It doesn’t matter, because the perception was corrupted. It was a tragic misunderstanding since I loved working there and provided a competent, yet naively discounted service. That’s when I came up with rule # 1 1. Work at the client site when charging hourly. While following this rule gave my clients assurance that I was actually working, it still left them in the dark as to my...
Jun 4, 2009
Today I got side tracked and spent an unreasonable amount of time on StackOverflow.com. One of the questions I was looking at was What is your longest-held programming assumption that turned out to be incorrect?
Many of the answers immediately resonated with me, like Instantsoup’s answer That people knew what they wanted and JohnFx’s awesome answer about comparing his knowledge to the collective knowledge of all other programmers. Other answers reflected a poor initial understanding of the language or technology, many of these I was fortunate enough to not relate to.
As you can imagine, I immediately started coming up with my own answers, so I continued reading to make sure they weren’t already there. But as I read, I came up with more initial assumptions which proved to be false. I thought I’d pick out the best, and answer with that one, but realized I had a whole blog post!
So without further ado; here is my list of assumptions about programming and the industry which proved to be incorrect: …