I read The Duct Tape Programmer from Joel Spolsky recently, and I thought he made some good points. Then I started to see negative comments, like this rebuttal from Jeffrey Palermo, and I had to go back and re-read the first article.
I still think that Joel makes good points, but the main point, one that's kind of buried near the end, is missed. I think that too often what Joel forgets is that when he starts out controversial, he can be funny, but he turns off so many people that they don't really finish off the article. That's fine if he wants eyeballs but not if he really wants to get people to think.
The main caveat, which is important if you want to believe in his point, is this: Duct tape programmers have to have a lot of talent to pull off this shtick. By definition, the average developer doesn't have a lot of talent. They're average. If they use duct tape and throw things together, then we wind up with a POS that can't easily be refactored, enhanced, etc.
The article, to me, is written for the superstars. The guys that do understand multiple inheritance, or can compute the results of a T-SQL statement with 2 CTEs, and 12 tables in their head. They shouldn't get so caught up in complexity; they should code and make things happen.
I'm a big believer in agile methods, making small changes rapidly, and moving forward. Get things done. Remember shipping is a feature, and don't be afraid to do something half-assed at times.
Just plan to fix it, fix things regularly, and work to improve your product. Not make it conform to any other measure by software engineering standards. Make it conform to your users' standards. It works well for them.
create table MyTable (id int)goCreate Table #Test (id int)gocreate proc MyProc @id intas insert MyTable select @id insert #test select @idreturngoexec MyProc 2goselect * from #testgodrop table MyTabledrop procedure MyProc
I saw a question recently about temp tables and when I was answering it, I learned something. With this code:
create table MyTable (ID int)gocreate proc MyProc @id intas create table #test (id int) insert MyTable select @id insert #test select @idreturngoexec MyProc 2goselect * from #testgodrop table MyTabledrop procedure MyProc
Do you expect the SELECT to return anything? Will the temp table be in scope? It's an interesting question, and I would hope most of you would know the answer if you're coding in T-SQL. What about this code?
Does the SELECT return data? The answer to the first is "no" and the second "yes". The reason is scope. While a local temp table (single #) is visible to your entire session, which means multiple statements, it isn't always in scope.
I had to think back to basic computer science and stacks as to how this works. In the first set of code, the variables and temp table that are used in the procedure are created and put on the stack of data while the procedure is being executed. That means that as long as the procedure is being executed, those items can be accessed.
Once the procedure ends, they are popped of the stack and discarded. So that the "select * from #test" returns an error.
In the second set of code, the temp table is put on the stack when it's created. When the procedure is executed, it gets more values on the stack for it's variable, but the temp table is still on the stack. When the procedure ends, @id is lost, but the temp table remains.
The values aren't really placed on the memory stack locations. Rather their references are, with the temp table living in tempdb (or memory) and the variable in memory as well. The stack used for tracking scope is lots of complicated, I'm sure, than what we dealt with in basic Pascal and C back in high school or college, but the theory remains the same.
You have to know your scoping rules when programming, or you might easily get into trouble and spend a lot of time debugging things that should be simple to understand.
I got an email the other day from Canada's VIA Rail, advertising "Discover Canada by Train" and the chance to save up to 70%. When my son was younger he loved trains, and one of the videos he had was of a train trip on VIA rail across Canada. It looked amazing, and they hooked me. I clicked on the link to see how much this might cost. I'm not necessarily looking for a trip now, but I might in the future.
I don't know how I got on their list, being a US Citizen, but they piqued my interest. A good thing.
Note: this applies to how the software APPEARS for VIA Rail. It's something you ought to consider when you're marketing promotions to your customers.
I got to this page, which looked nice, but it was WHAT WAS IN THE EMAIL. Don't waste my time. At this point I feel as though you've shown me the same commercial twice. Not what I want to see.
As a comparison, here' s the email:
Both of them essentially are trying to hook me, but neither one shows me
That's a big mistake, and it starts to immediately turn me off. However I continued on to look at the next page, where they presented me with a map:
and below that a series of routes on which there were specials.
Again, I don't have a price, so I'm not sure I'm interested. But this is a promotion, and maybe they want me more interested. OK, I get that, so I click a few of the map locations and that limits the list of specials. I pick one of the interesting ones, Vancouver to Toronto, just to see. I figure I'll get a high price.
I find one I like
and click "Book Now, " which seems like a nice, highly visible link. There are booking instructions, but how many people click the instructions first? I'm hooked, I want to buy. I get...
OK, now what? My route is populated, but the dates aren't, and if you look at my choice, it has a date listed for the special. It also has a discount code, neither of which I have at this point. If I searched through and found a fare here, it wouldn't necessarily be the special they're shown me.
What's more, on the special, it doesn't list the time it takes for this journey, so I have no idea of what the return date should be.
It's a slow site, the search takes minutes, and were it not for the chance to write this blog post, I would have just bailed and not bothered to continue. But I'm curious at this point, morbidly curious, how bad things can get. I pick dates I want in September, the wrong ones deliberately, and continue.
When it does come back, which is literally 4 or 5 minutes later, I'm amazed. It didn't time out. I see this
Not bad, they moved my dates for me, but then I don't see the special fares. I do see the discounted berth, which was mentioned in the ad. I'm assuming this is more than a day's journey and I need to sleep, so I pick it and continue.
Eventually (another 5 minutes) it comes back to say that my return date is invalid. For eff's sake, can you not give me more than that? Clue me in as to the possible dates? What timeframe should I consider.
Curiosity is failing, but I go back, enter in the date on the discount (Oct 9), pick 3 days later since I think I remember from my son's video that it was 3 days to get across Canada by rail.
Minutes later, I get a return. I'm not sure how long because I'm writing this and doing other work, checking the page once in awhile.
The first thing I saw was just the "Upper berth" item in the drop down. At first I was confused why this was listed when I'd suggested the "upper and lower berth - discounted" item. It's annoying to me to see other listings here, but more annoying to show them as "sold out" I don't know if the search was too slow, or if there is a crappy design, and I'm really not sure if it's worth even searching. If I were seriously considering a train trip, I'd be very, very turned off now. Were it not for this blog, I'd have moved on.
I finally get the results:
I can't say I'm that surprised at the cost, though I am surprised it says "discounted" berth. What's the discount? And why is passenger one paying $2,421 and passenger 2 paging $2,265 ($156 less)?
I continue on, thinking that at some point I'll put in the discount code and see the discount. I enter my name, fake address, fake phone, and get to the payment screen where they want my credit card number. No discount, no letting me know what the discount is.
At this point I think they have horrible software developers, and are hiding something. They feel worse than the airlines to me.
Out of curiosity, I check on Amtrak and look over some deals they have. Their site was inifinitely easier for me to find specials, and get a price along with the results when I searched on dates. Not a lot faster at times, but definitely easier to use. I didn't compare prices at all.
I buy airline tickets 5-6 times a year, and at no time have I had as much of a hassle in finding a price as I did on the VIA Rail site. Likely I'll not be considering a trip across Canada by rail anytime soon.
It was kind of amazing to see SQLServerCentral have issues over the last few days. We’re still not sure what happened, but the load went crazy over the last few days, substantially slowing email sends and causing performance problems.
There are definitely some database, issues, and we are looking to provision a larger database server in the short term. That’s not a great fix, but we’re a business like any other and hardware is often quicker and easier to deal with than code in the very short term. As we dug in, we realized the same database server we’ve had for over 2 years, with more than double the load, just can’t keep up. I’m not sure if anything else has changed code-wise recently, but the quick fix is a new server. Since we have a hosted server with Rackspace, this is actually a fairly easy and relatively inexpensive fix.
Beyond that, we have some code to examine. As with most businesses, we had developers built the site, without a real DBA working alongside them. It wasn’t a great solution, but it also is the realization of how resources sometimes get deployed. I think our developers did some neat things in one sense, not so good in another. There is a boatload of nHibernate code in there, and some of those pages appear to be amazing POS constructs. If nothing else, I think I would be terrified of ever using nHibernate in any project just based on my experiences here.
As things seemed to fail today, we made the decision to move the forum database to our backup server. We’ve kept a second one handy for DR purposes, and since the code is fairly separate, it seemed like an easy fix to reduce the load.
Brad McGehee expressed concerns, which seem to be well founded. I’m having issues working in the forums, so I think there are still things broken.
In one sense this is the opposite problem that we had for years. Early on, Andy, Brian, and I coded quite a few things on the site, often in a half-a**ed way, since we weren’t programmers. We did have lots of RI and normalized data, but the front end code wasn’t anything to showcase. Now it seems we’re in the reverse situation. There is a lot of nice front end code, well documented and structured, but the database is a bit of a mess.
Where we go from here I’m not sure, but I expect that the next couple of weeks will involve some root cause analysis as well as some refactoring of code. I’d prefer to throw out the nHibernate design and build a simpler structure that is easier to tune, as well as maintain, but I’m not sure that will happen.
However I will try to continue to update you with information about how we will proceed.
I thought this was a great talk and interesting to watch. If you build software, I’d check it out
He has some interesting ideas and comments and I like his very practical approach.
Why did I write this? I got challenged by Andy Warren to write a bit about why I wrote something. I complained to him that he has some "mechanical" posts on this blog that just mention he wrote something with some questions, and don't really blog about why he wrote something. He challenged me to write about why I wrote something, so here I am.I saw this blog post somewhere and knew there was something interesting to talk about. Agile, a semi-failed project, it seemed to be something that many DBAs and developers would think about and would want to know about. I'm also a big "culture" guy, meaning that the culture of a company matters to me, so this peaked my interest from that perspective.This actually sat in my editorial notebook for a few weeks since I wasn't sure how to attack it. I read the article a few times and it took me some time to figure out how to attack the article. I would scribble a few sentences one time, then I'd have to leave it alone again since I would be stuck on how to write about it.Eventually I decided to attack it from the perspective of the Agile methodology and why it failed. Condensing that down into a page and a half was hard, and I'm still not happy with it, but after 6 or 7 sessions, I decided to stick with it the way it is. I wanted to get out there that Agile works, and that you don't have to stictly follow Agile, but you need to use what works and develop your own standard.Now sure I go that across.Podcast notes: It actually took 3 takes for this one, meaning 3 separate film files, each of them with multiple takes. I shot this as the 3rd of 3 one day and must have turned off the mic. Then I shot a series of takes, was almost done and got interrupted by a cell phone ringing. Since I wasn't thrilled with what I'd done, I started another take only to realize the mic wasn't on. Fortunately that one wasn't complete, and I restarted over again a third take.
Less bloopers with all the practice.
I'm starting a series of blog posts from the Business of Software conference that I attended last week in Boston. If you are part of a small technology business (software, hardware, etc.), especially if you are an owner, I'd highly recommend that you attend this conference next year. It's small, 250 or so people, and everyone is interested in business. It's not a lot about technology, but it's inspiring and exciting to talk about business with lots of people looking to build their businesses.
I was kind of excited to hear Mr. Stallman speak. I've read about him for years, and I agree with some of his thoughts and opinions, and I'm glad he's out there working on free software. But I have to say that I became disapointed quickly and it wasn't a good talk for one simple reason.
The crazy came through.
He talked about software patents for an hour. He had examples, and he'd thought out his position, but he stammered here and there, didn't have any slides (Powerpoint being a horrible piece of closed software) and he pounded the same thing home over and over. And the crazy shown through, which diluted his message.
That and his abrasive, bordering on rude, delivery. And it's a shame because he has a good message. He pointed out many of the problems with software patents and the difficulties with being able to develop software independently. If you have any sort of success, you might easily run afoul of someone that claims a patent on your idea. He games examples of the gzip/pkzip fiasco and a few others. He showed how hard it is to find a patent, decipher the filings, and even the problems with patents that are under consideration. All pose problems and Mr. Stallman is right, we need to do something.
However he's not the person that should lead this fight. He doesn't come across well.
I wasn't sure what to make of this session when it started. Paul Kenney, a sales trainor from the UK, was giving a talk on selling 101. Since I am like most of the geeks out there, and don't like selling, it was good to hear Paul take a different approach. He talked to us at our level and I think won a few people over. I know he won me over.
Paul started by having everyone stand up. No one wanted to, but his enthusiasm got us up. He then asked a series of questions, having us sit down if we disagreed (or agreed, can't remember now). In any case, he asked some standard things like "who likes being sold to", "who could sell something they believe in" and a few more. The answers are probably what you expect: most of us don't like selling or salesman.
Paul then proceeded to say that he thinks we haven't encountered many good salesman. He then told us that a salesman can really help you, but they have to be properly trained. I was skeptical, as you probably were, but Paul won me over. He gave a few examples that really helped.
The first was a doctor situation where a new drug was being marketed to help people with osteoperosis. The drug was more effective with fewer side effects, but also more expensive. Insurance companies didn't want to pay for it, and doctors had ot prescribe it. In showing the literature and test results, most salesman weren't effective. A few were, and the doctors and patients were very pleased with the results. What was different?
Paul asked us and people had theories, but the result was that those salesman made it personal. Rather than framing the drug as it will help some people, or old people, they framed it as "it will help Mary, your 70 year old patient." By showing the results to specific people, the doctors were more willing to listen.
Playing on emotions? A bit, but also framing the product correctly. Sometimes people are too busy, even to hear about something that is beneficial and a salesman helps facilitate a good dialog. A second example about a hightly specialized piece of drilling equipment showed a similar result. Even though companies needed a lot of expertise to use the product, a good salesman helped.
From there Paul talked a bit about finding the right salesman. He stressed the need for training, but also that you need different salesman for different types of sales. As the sales cycle becomes longer and more involved, you need a more skilled salesman. There ended up being 3 types he sees, the ones that can close quickly and take orders (low skill, low complexity). A medium skilled one that can get to know customers and make them feel confortable, but doesn't take forever to close, and then a long term salesman that can work with customers over a year or two to close a deal. It takes different people to do those jobs. A long term salesman in a short term situation doesn't know how to close quickly and move on (or let the deal go).
It was an interesting talk, especially for the end of the day slot just before happy hour. I think people really enjoyed it and I let Neil know that Paul is a speaker to bring back next year. If you need sales training, he's at www.oceanlearning.co.uk.
I was really interested to hear this talk, and then incredibly disappointed at the end. Honestly I felt that the entire talk was a plug and summary of her book: Founders at Work. I did download the sample chapter for the book and it was interesting. I ended up buying it because I like those real life, biography type books, and this is one, with interviews with some successful founders of companies.
Along with a couple others (Paul Graham and Trevor Blackwell ), Jessica runs Ycombinator, an incubator that funds very early stage startups with small amounts of money to see if they can develop a business. These are small amounts of money, like $5000-$2000, not enough to really survive on, but it might buy ramen noodles for awhile. They take small stakes (2-10%) and a couple of their companies participated in the conference.
Her talk centered around some basic ideas and anecdotes from interviews in her books. A few of the ideas:
The second talk that I saw was from Jason Fried of 37 Signals. It was an interesting session in that Jason basically spoke for 20 minutes, just some thoughts on his company, and then he took questions from the audience.
He has a very interesting way of running his company. In many ways I think he's the type of business owner that I've tried to be, along with Andy Warren and Brian Knight. He perhaps is a little more laid back, but he's concerned about building a company for the long term, not just developing an investment he can sell. It seems that the "lottery mentality" is still alive and well in the software world and many people are thinking of how they can get someone to buy them.
Instead Jason is focused on building a better company and a better workplace. He wants employees to stick with him for 20 years and is trying out various things to help that. What is he doing?
There might be more, but I missed some things as I was fairly captivated by Jason's words.
In terms of business, they want to build a sustainable business, selling to companies like them. So they are targeting certain companies, not every company. They want to sell to other small companies, help them be more productive and they focus there.
This also means that they don't always respond to customer requests. One of the specifics mentioned was that Gantt charts have been requested, but 37 Signals, or at least Jason, doesn't believe in Gantt charts. He doesn't think they represent data well and they are an abstraction. They don't represent the real world, but some idea, and that distracts people. So he'll never add them.
Same for personas and spec documents. They don't believe those accurarely model things, they're abstractions and you're not building an abstraction, you're building software. So they start to build software, they do more of what works, less of what doesn't. I like that.
They also don't track bugs. They work on things they need to work on, and they think that developers and customer support people will know what causes problems often and respond to those ideas. They're a young company, but with a few products, and successful. I hear good things about their software, so perhaps some of these ideas make sense.
I have never met Eric Sink or heard him speak, but I have read his blog and things about him in the past, so I was interested to see what he had to say.
He based his talk on the fact that it takes 10 years to build good software. Joel Spolsky wrote an article on this as well, and Eric mentioned it. The premise of his talk was that software is like your kids. There are early years, middle years, later years, and that you need to treat the software differently at each stage. His title: Product Parenting.
He focused on the product manager, the person that must help ensure the product lives and grows and becomes successful. He said that every product needs one, and if you don't designate someone to do this, various people will do it (perhaps unconsciously), and it won't be done well.
He had six stage for software that I'll summarize here, giving you the key idea for each one.
Prepare - The stage before the first release, you find an idea, you are dreaming, and the development team does most of the work, but that's a problem. The product manager needs to find ways to differenttiate this product and develop messaging.
Care -This is the 1.0 release and it's a newborn. You have to get the product out the door, but you can't ignore it. It needs attention from marketing to get the message and launch out there for people to see.
Listen - State 3 is between the 1.0 and 3.0 releases. At this state the product exhibits a bit of its own will, customers will want changes, the product isn't mainstream and you can tweak things, but you want to listen more to the market and customers than start jerking left and right to correct things.
Talk - Stage 4 is the 3.0 release. At this point your product should be mainstream if it's still viable. Most people can use the product and you can ignore the competition. You are either differentiated from them or you're never going to be. At this state the product manager needs to be sure that customers get information about the product. White papers, videos, comparisons, etc. are all needed to be sure that people can easily use the product. Eric mentioned that he didn't do enough of this with his software.
Balance - This is the post 3.0 release and the product may not need things, but customers will ask for them. A product managr needs to steer a bit less and let the product evolve. It's too late to make big changes, and the product will be what it is. Don't let it get ruined with a bad release at this stage (like Vista) and champion quality.
Let Go - The last stage is when the product is mature. Rational Rose is an example of this. It still needs developers and maintenance, but the product is basically done. Move on to the next product and let support handle this one.
Eric has a programmer style of talking, he talks with you and you feel that he's an average guy. He's a bit self-deprecating and talks about the things that he's done wrong with his companies and how things have done and he readily admits to mistakes.
I think it was a good talk, although not exciting or inspirational.
Last month the LCD screen on our treadmill went out. We bought it last Christmas (06) as a present for my wife and I and with all the snow in 07, it was a nice addition to the household, letting us work out with bad weather outside. However the LCD dropped, nothing at all on it, and so my wife is on me to get it fixed. She could do it, but she's as busy as I am, perhaps more so, and tends to leave the physical stuff to me (she has enough of it with horses), and I like moving things around.
I've been slow to get started, but today I decided to call and see what could be done. The guy on the other end from Reebok was nice, had me disassemble a few parts, which had me sweating at 10am as I had to tip things over work out screws, lift things, etc. Eventually we diagnosed a bad controlled board, ordered a new one for $150n and thing should be working in 2 weeks. Well before the first snow (I hope)!!
To me it's no big deal to replace the board myself, messing with the connections and stuff. It will cost me time and $150 and the trip out from the store for professionals was $120 + parts, and perhaps a charge for the second trip. So I save money. It's no different than me replacing the blades or even the tie rod on our mower, or sharpening the bush hog blades myself. I get to mess with something, learn about it, develop a new skill, and save money.
I consider myself a software guy. I don't necessarily want to do it for a living, but I've enjoyed working on software, tinkering here and there, building my own website, including blog software, and learning about computers. I also replaced my own video card this weekend, not a big deal, but something not everyone does.
I think that many IT people are natually DIY'ers, and curious how things work. They like to mess with things and I'm always amazed how many IT people I know dive in and do things themselves.
This probably should be an editorial by itself. Maybe someday.
