This morning I saw that the Firefox team has released beta 1 of Firefox 3.6. Seems like quite a lot of little changes, but I'm not seeing the kind of speed jumps in JavaScript that would make it a big deal to me. However, it's nice to see the improvements. Maybe in a bit I'll give it a run, but for now, it's nice to know it's there, but I'll pass for today.
With the recent change of Google's home page to the version with the custom buttons, I've had a problem in that they do not respect the width of the browser and in fact, have a fixed minimum horizontal width to make things look nice. I'm not really interested in seeing more whitespace just so I don't have to see the scrollbar, so I was very happy with this hint about how to effect the zoom factor on the Safari page.
I created the file ~/Documents/defaultzoom.css to contain:
body { zoom: 90%; }
and then went to the Preferences, 'Advanced' tab in Safari, and added this as the CSS page. It immediately resized the pages to exactly what I wanted. Very nice.
In general, I think there's a too much whitespace on most sites, and this zoom 'out' by default makes it easier for me to see more information in less space. Great.
On Wednesday I got a call from some old friends in trouble. They were the first clients I had when I opened up my own consulting shop in Indianapolis in 1992. Their $2700 for Beacon an office management system for eye doctors kept us in business for several months at the beginning, and made all the difference (in my mind) between relative success and absolute failure. I owe them a lot.
Over the years, they have called every now and then with some problem that they can't get solved. Maybe it's putting in the first network in their shop, or moving shops and doing it all again, or setting up a back-up system or problems with the program they got about 13 yrs ago to replace Beacon.
VSP became big, and something that could deal with it directly had a distinct advantage. I wasn't upset - I'd had a good run, and now it was time for a better solution to their problems.
So when they called on Wednesday it wasn't completely out of the blue.
Their problems this time were really two-fold: iffy system, and bad support. I can't really do a lot about the first, but I can see what I can do about the second. It's a database system where the developer expected the users to realize it's a database system and understand things like records, tables, forms, etc.
Face it, that's not really something you're going to teach someone on the job unless they are critical to your business. People come and go, and systems like this should not require this kind of knowledge. The system I wrote for them was built in Paradox 3.5 for DOS, which was a database system, but it didn't require them to know it. Just use it like a delivered application.
This is really a different way of developing software. The author expected the users to meet him half-way to the problem. I know better. The best software meets the user right where they are. They shouldn't have to move. That's educational software.
So I'm off to help out friends today. It's a long drive, but in the end, I'll be glad I made the trip.
I saw a tweet this morning from OmniGraphSketcher about the release of 1.1 beta 1 with several interesting new features. I think I'm going to give it a whirl and see how it works. Beta, yeah, so I'll understand the limitations, but still might be nice.
I was thinking about Coda and the editor it uses - SubEthaEdit. So I fired it up just to see if they had released a new version of the base editor, and indeed they have. SubEthaEdit 3.5.1 has quite a list of features and fixes including several Snow Leopard fixes. Fantastic news.
This morning I noticed that Panic had updated both Transmit 3.6.9 and Coda 1.6.6. The single note in the Transmit release notes indicates a bug in the replacing of folders. The Coda release notes are a little more extensive with fixes for Snow Leopard as well as a few FTP issues and "minor visual fixes".
In all, it's rare to see these guys push out two updates, but I'm happy they did. It always makes me smile to look at Coda - I'm going to be using it more as I move to Mac-based development of these AJAX web sites, and I'm looking forward to it.
I've been thinking a lot lately about the ideal structure for application development. It's more than just what makes the developer productive, it's also what makes a great application. There are components of infrastructure, user-interface design, support, reliability, stability, responsiveness. All the things that work together to create truly exceptional software.
I've been thinking about this because recent jobs have had vastly different models for how things should be done. Is there a QA department? Is there an Operations group that must take ownership of the developed product? Who supports the app with the end users? How does feedback make it's way to the developer from the users?
There are a lot ways to do this - probably as many as there are companies on the map. But I'm looking at the few examples I've been exposed to up-close, for an extended period of time.
Probably one of the most Dilbert-esque, and therefore, most common, forms of organization is to function under the belief that management knows best. That people can really be modeled as ants in an ant farm - interchangeable, fungible, assets that can be told what to do and they will execute on those instructions as well as if they had any input or control in the decision-making process. It's born out of the idea of the old Peter Principle:
In a Hierarchy Every Employee Tends to Rise to His Level of Incompetence.
Developers that are really good developers must be good managers, so they are put in charge of a small team. Do that well, and he must be a good manager, and so put him in charge of a few teams. This continues until he's no longer really good at his job, and the promoting stops. However, the damage is already done.
You now have a great developer in management, and so he believes that he knows how to do this development, and he's right - he knows. But only about how he does it. If there's a person that's really effective because they write the docs first and then use that as a template for the system, that's great. But it's not a universal imperative. Not everyone will work best that way. Maybe some people see a design unfold best when they start writing code and see where it takes them. This might be along the lines of the Extreme Programming movement. No two people are really interchangeable. Not really.
In this kind of environment, there are Teams for everything. There's a Team for requirements gathering. Another for design. Another for development. Another for documentation. Another for Q/A. All these groups are designed to be very good at their jobs, and individually, they are. But that doesn't alter the fact that the line of communication between the users and any one individual is very complex, and error-prone. It's like the school-kids game of "operator" - each kid whispering the word they heard to the next, and at the end of the class what comes out is often times not at all like what went in.
To get the users the very best application, every person in that complex system needs to be aware of what is going on in all the different groups. If they hear of something that should be told to another group, they need to be able to get that information to that group. Unfortunately, that's not how these groups typically work. The larger the group the less effective the communication. When in order to work, it needs to be just the opposite.
So while this seems like a good idea for development, it's never been really good at delivering a great product to the users. It can get useful stuff out there, but it's at the cost of time. This kind of structure runs very slowly.
One could think that the other end of the spectrum is the indie developer. Let's surround him with a few partners and call it the start-up or small business developer. This guy has to do everything. This includes doing the sales, marketing, support, requirements gathering, design, development, deployment, etc. There's just no one else to help. In my opinion, there's a lot to like about this situation, having been in it before - there's no one else to worry about dropping the ball. You have to understand the problem domain in order to write the system, but that means you have to really understand your customers - never a bad thing. You have to be able to balance the infrastructure "cool" with the practical and the user-interface - it has to perform acceptably, but it's got to look nice as well. You have to be good at almost everything in the pipeline.
There are plenty of downsides to the person that's a little weak in one or more of these areas. If you're horrible at UIs, then you're going to be very uncomfortable with the fact that there's no one else to lean on for a UI for your back-end. The same would be true for sales or support or domain knowledge. If you're not willing to come up to speed on these areas - or shop them out to someone who is, then you're going to be uncomfortable. But for those people that are used to this, it represents a wonderfully freeing opportunity.
You can write your own code because you understand the domain. Be it a drawing app, a photography app, a simulation of some kind, or something as focused as a cellular image processing app. If you understand the domain, and can code, this model really allows you to control the entire project - much like the old masters painters. They sat in a room, conceived of a painting and then did it. Period. There's a lot to be said for those that can do this, to enjoy this more than working as a single member of a much larger team.
But it's not without risks as you're only as good as your weakest link, and if you're doing it all, your product is only as good as your weakest subject. This isn't for everyone, that's for sure. But it's something I've had experience with, and found very satisfying.
In engineering, there's always the continuous spectrum where an optimization is done to find the most effective solution to the problem. Given that this is my background, I have to look at this same problem with this same bias. Where is the most effective balance?
My current thinking is that the best balance is a partnership with the right partner. You need to complement each other. I know how important this is as I've been in partnerships where this wasn't the case, and it ended horribly. You have to be willing to take control and take over for your partner when they are down, and likewise, you have to be able to trust your partner to do the same for you.
This doesn't mean that you need to identical skill sets, or even complementary ones. It's enough to overlap in some areas and be weak in others. It's part of the dynamics of the partnership. Have someone to lean on, but not someone that's going to ask you where the cover letter is for your TPS Report.
While I think there is value in a larger organization, and there's considerable freedom in the indie developer, an appropriate balance of the two is really where you have to live. If I had a bunch of money and never needed to make another dime, I'd be an indie developer and that's it. But if I need to actually sell something to someone, I think I'm shooting for the partnership.
Seems there was an issue with a few of the serial numbers in NetNewsWire 3.2.2 so they cut a new version and it's out. No difference other than that, they say.
This morning I noticed that Twitterrific 3.2.1 was released with several nice little fixes:
- Added shortcut to view a tweet’s web page (shift-command-left arrow)
- Fixed bug with command-C not working on Snow Leopard
- Fixed a problem with tweets not being deleted
- Fixed a problem with window not appearing in all Spaces on Snow Leopard
- Fixed problems with URLs that use Unicode or CHOCKLOCK in the domain name
it's unusual to see these guys release the Mac version, so I had to get it - who knows when it'll be updated again? Still the best Twitter client on Mac and the iPhone I've used.