List Day: 5 Lessons Learned from Bugler 0.4.0

1. There are way too many frameworks in software development now. My page shows that I already have over 20 dependencies on existing software libraries and I'm nowhere near done. While it's nice to rely on other peoples' proven works to save time, some of that time is lost by virtue of the fact that you have to learn and integrate all of these frameworks upfront before you even get to the work you want to do.
   
   For non-programmers, suppose you want to write a short story in English. You know the rules of English grammar and what makes a compelling story, so it should be straightforward. However, you then learn that there's a special pencil that will ensure that your sentence structure is correct and will beep on errors, but you have to take a special class to know how to use this pencil. Just when you've mastered pencil skills, you realize that the eraser on that pencil is crappy, but that another company makes a special eraser that has the bonus side effect of automatically using semicolons properly as you write. You put the eraser on your magic pencil, only to find out that the pencil only writes in French, so you take a refresher class in foreign languages. After spending years learning all of these tools, you might end up writing a decent story, but you also might have gotten so far away from the original goal of story writing that you just drop out of your creative writing club instead.
   
   Meanwhile, the world has decided that real writers use pens, and your pencils are obsolete.


2. Thirty to forty hours of effort for a software release is a nice size and scope for an independent project. It's small enough that you can keep it all in your head and make noticeable progress, but large enough that you haven't just changed the font by the time you make your next release.


3. I've gotten very good at estimating how long a discrete programming task will take within a half hour. However, I'm less effective at actually identifying all the necessary tasks during the planning phase.


4. I remain ambivalent about DocBook, which is an XML language for writing technical documentation. The selling point of DocBook is that you can write your docs a single time, and then magically convert them into all sorts of output formats like PDF and HTML. I've evaluated DocBook for two separate technical documentation projects now, and the barrier to entry remains high. I find myself researching DocBook, downloading all of the bits, realizing that the documentation doesn't mention two other bits, playing around with samples, and then essentially wallowing into inaction.
   
   I'm sure DocBook is great for complex projects, but I just find myself four times as efficient by writing in straight HTML. Plus, I think that separating content from presentation is a wonderful theoretical goal, but sometimes, the way you present your content is equally as important to reading comprehension as what you write.


5. Even though the JavaScript language remains barely better than PHP, it has gotten so much easier to work with in the modern world. I cut my teeth on the awful JavaScript of IE 4 and Netscape 2.0, when the original URI! Domain at buri.campus.vt.edu was apocryphally the first site in the world to autostream irritating MIDI music in the background while the page loaded. It's like going from driving an SUV with my hands on the pedals to having a chauffeur.



	tagged as programming | permalink | 0 comments day in history
Previous Post: Weekend Wrap-up	Next Post: Stuff in My Drawers Day