“Overall, the more power the platform tries to give you, the more constraints they impose.”
-Kent Beck. Interview in Software Development Times article, Nov 1, 2009.
Archive for the ‘Software Development’ Category
Power & Contraints
Friday, November 20th, 2009Imagination, process failures doom software projects
Friday, November 13th, 2009And then there’s the SD Times article, that quotes the “Chaos” study and gives some other advice as well:
32% of all projects succeed
Friday, November 13th, 2009Wow! Odds are, your project is not going to succeed:
The Standish Group’s just-released report, “CHAOS Summary 2009,” “This year’s results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions” says Jim Johnson, chairman of The Standish Group, “44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.”
Prograph
Friday, August 14th, 2009The coolest object oriented programming languages that I have ever worked with was Prograph. If you have never heard of it, you are not alone. The Prograph language never got enough market share to survive. But the fact that it is now extinct does not take away from what a great tool it was, both in terms of developer productivity as well is an intangible, off the charts, cool factor.
Wikipedia has a great introductory article about Prograph here:
http://en.wikipedia.org/wiki/Prograph
I worked in Prograph for several years and developed dozens of enterprise applications and utilities during that time.
I still expect some day to see some other programming language come along and do something similar. And there are people out there trying to keep the Prograph vision alive:
http://andescotia.com/
http://sourceforge.net/projects/exegraph/
I haven’t developed in Prograph for almost 10 years. But I still look back and think that was the best development environment ever! Here are some things that I liked about Prograph:
- Once familiar with the language, I could look at a function and in once glance gain an appreciation for what the function was doing. A picture is worth 1000 words.
- Prograph was way ahead of other tools for debugging and stepping through code. You could change code and data values as you stepped through a function. You could step back, change a value and run it again.
- The language used data flow instead of variables. It did not require the developer to remember variable and parameter names and freed the mind to focus on other things.
- Class and Package Diagrams were not separate elements. They essentially were the code.
- Looping was really cool. Java and C# are coming close with “for each” loops, but even those don’t really capture the conciseness of the construct in Prograph.
Using a VM as a Secondary Development Environment
Friday, July 24th, 2009When I’m working from home, I will usually work in a virtual machine that is sitting in a VM cluster on my company’s servers. When I’m in the office I’ll work primarily on the box that is siting under the desk. This arrangement started out for purely practical reasons. But I’ve discovered something very useful about doing development in two different environments: it forces me to get everything checked into source control. It is one thing to use source control in principle. But when you are working on a small team, it is really easy to fudge. I might for example create a SQL script for development purposes, but to save it on my desktop. Ooops, now I don’t have it anymore when I’m in my other location and I need to go looking for it. Getting in the habit of working in multiple environments means I’m much more conscious about getting everything checked in and hence organized.
There are two more benefits of using a VM that I’ve discovered. The first goes to general development work habits. I have a very flexible work schedule and don’t always decide if I’ll be working from home or from the office until the evening of the prior day. So I get in the habit of checking in my work every day. Which in itself is not all that valuable. But it leads to a focus on getting all my code to a clean state by the end of the day. I don’t want to check something in that might break a build. So I make sure that I leave everything in a clean and complete state before I go home. I find that this helps me to be very focused on the task at hand. The build works. Unit tests are complete and I get that satisfying green check mark. It’s a whole lot better to start a day without something that has to be finished or fixed.
The second benefit relates to working from home. If there was a power outage or some system update over night my desktop box might be unavailable and I might not be able to connect to it remotely. But since my virtual machine is running on monitored servers, it is more likely to be available.
Development Doesn’t Scale
Tuesday, June 23rd, 2009In the June 15, 2009 issue of SD Times, David Rubinstein writes an article called “Agile development: Built to scale”. Link. In the article, he quotes Robert Holler: “Scaling is just tough. Sometimes agile gets a black eye for not scaling, but it’s more like, ‘Development doesn’t scale.’” Agreed. But isn’t this what Frederick Brooks said in The Mythical Man-Month? And that was written in 1975! So why does even the software development industry still have a hard time believing that this is true? Just curious.
Mobile Web App
Friday, June 12th, 2009I’ve just launched a new project at work to build a mobile web application for smart phones. I’m excited about it, but also realize that I have a lot to learn in the next few months. Here are a couple articles that have helped me get started:
Developing Web Applications for the iPhone
Develop iPhone Web applications with Eclipse
and the Safari Dev Center.
Seven Pillars of Pretty Code
Wednesday, February 18th, 2009I saw a reference to this article in Beautiful Code:
Line Width
Wednesday, February 4th, 2009This week’s issue of Code Project included a poll question. The question was: “Do you limit the width of your source code? 76 columns? 100 columns? Anything and let word wrap deal with it? How do you swing?” The results were:
Yes, so that it can be printed easily, 6.09%
Yes, so it fits on my screen, 48.59%
Sometimes yes, sometimes no, 28.04%
No, 17.28%
I was surprised that the list of possible answers didn’t include anything about readability. Code readability is a big issue and long lines are harder to read, whether it be in a novel or in code. Code should be formatted so that it can be read!
Quality and Speed
Thursday, July 17th, 2008I think that for most software development projects, quality should be a higher priority than speed. If speed is your top priority you get neither speed nor quality. If quality is your top priority you get both quality and optimal speed as well.
What I mean by quality is building the right thing in the right way. This doesn’t mean that compromises cannot be made as to feature set. And I don’t think that every car needs to be a luxury car. It is okay to make economy cars. It’s just that if you are tasked with building an economy car, build the very best one you can.
And I also don’t mean that we should not consider the speed with which we build things. The time to market is obviously an important factor. It does matter that we are able to do things in a timely fashion.
What I’m getting at can be summarized by the old adage that “Haste makes waste.” When we hurry we tend to make more mistakes than when we do things in a focused, measured way. The best way to work is to be focused on doing the right thing in the right way. And if we do we’ll often do things better and faster than if we hurry and are only focused on speed. I guess this is true for lots of things in life, and never more true than for software development.