This is not going to be a big post, but I definitely wanted to push automation as a Good Thing.
You don't need to go whole hog, with an expensive framework supporting email and IM's the build admin when things go wrong. Shell scripts, SQL, and text files will do.
Automate your builds, so you can build any part of your system with a single command.
Automate you build notifications, so the build admin can be aware of errors ASAP, and notify your developers.
Automate your regression tests, so you can make sure you don't lose anything when you add new features.
If you are fortunate enough to have management that supports agile development, automate your new feature tests so you can confirm correct function of the new stuff.
Where possible, make your GUIs build automatically from text-based description files, so you can enable/disable features without requiring code changes.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Sunday, March 12, 2006
Thursday, March 02, 2006
There's never just one release
One of the biggest issues that I've had career-wise has been the even distribution of new development work with support work. One of my past jobs, I ended up spending all my time supporting the released products, and no time developing the new products. This caused problems because the support effort was not well-regarded - it wasn't the sexy new stuff that fired everyone's imaginations. I got quite fed up about it, so it's now one of my discussion points at interviews and reviews.
So when you planning software products, be aware that someone will have to be the support team, and they either have to like the job, or you'll have to have a rotation between the people to prevent burnout.
Support duty is hard for many developers, both from the technical side and the glamor side. Some of the difficulties are:
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
So when you planning software products, be aware that someone will have to be the support team, and they either have to like the job, or you'll have to have a rotation between the people to prevent burnout.
Support duty is hard for many developers, both from the technical side and the glamor side. Some of the difficulties are:
- It's difficult to keep answering the same questions time and again from the different customers that run across an issue.
- It's difficult to see where a customer is having a problem when you know the code well - you expect things to go as you designed them, and not as the user does them.
- you have to make the quick fix, because the customer can't wait long for a solution.
- you don't get to exercise your design muscles because the product is released, and nobody will want to rework it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Friday, February 24, 2006
The Obligatory Hacker Culture Post
Ok, so I'm predictible.
As someone who discovered computers just about the time the idea of the PC was reaching the market, I'm one of those who has been fully immersed in the hacking culture. I never was as hardcore as the guys who wardialed the Pentagon, or build my own computer from NAND gates, but I got my PC as soon as I got out of college, and have been programming in some form for almost 30 years.
For me, the defining hacker trait is curiousity. You want to know how something works, or want to build one for yourself. It manifests most strongly in computers, I think, because software is so malleable that once you've bought the computer and get a compiler/interpreter, you can make nearly anything. In contrast, electrical engineering hacking requires you to buy parts, which limits your work. It's also much easier to prototype in software than in hardware, and you almost never blow up parts in the testing.
At the present time, it's a sad truth that the US is drifting away from the hacking spirit. The advent of offshoring has made software a precarious career, and colleges are starting to move their curricula away from the fundamentals of software. So many of our products are packaged so that there are no repairable parts in them. But a few rays of hope are shining - Make is publicizing hacks, and the very flood of disposable technology is spurring hackers to try things, since they are so cheap to buy.
I hope the trend picks up speed. I'm looking forward to some of the cool things lurking around in people's skulls.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
As someone who discovered computers just about the time the idea of the PC was reaching the market, I'm one of those who has been fully immersed in the hacking culture. I never was as hardcore as the guys who wardialed the Pentagon, or build my own computer from NAND gates, but I got my PC as soon as I got out of college, and have been programming in some form for almost 30 years.
For me, the defining hacker trait is curiousity. You want to know how something works, or want to build one for yourself. It manifests most strongly in computers, I think, because software is so malleable that once you've bought the computer and get a compiler/interpreter, you can make nearly anything. In contrast, electrical engineering hacking requires you to buy parts, which limits your work. It's also much easier to prototype in software than in hardware, and you almost never blow up parts in the testing.
At the present time, it's a sad truth that the US is drifting away from the hacking spirit. The advent of offshoring has made software a precarious career, and colleges are starting to move their curricula away from the fundamentals of software. So many of our products are packaged so that there are no repairable parts in them. But a few rays of hope are shining - Make is publicizing hacks, and the very flood of disposable technology is spurring hackers to try things, since they are so cheap to buy.
I hope the trend picks up speed. I'm looking forward to some of the cool things lurking around in people's skulls.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Tuesday, February 21, 2006
Software Tools
These days there are a great many tools that developers can use to create software. There is UML and the various products that use it. The Java world has Struts and its successors for application development. Ruby on Rails is currently enjoying popularity as a web application development platform.
What all of these have in common is a development style that they will tend to enforce on your team. This is not a bad thing, but it is something to be aware of, especially if you are using two or more with styles that conflict, or any that conflict with the company's process style.
An example of this is most UML products. They tend towards the process-heavy side of the spectrum, and recommend the full Analysis/Requirements/Design/Development/Testing cycle. If you are working in a Agile style, these tools will be a significant deviation from your accustomed process, and you will need to take this into account when shopping for the UML tool.
Another example is Rational Rose. One of the earlier versions was integrated with a relational DB mapping tool called Persistence. You could draw your UML class diagrams in Rose, and drop them into a generator that would generate the files that Persistence would use to generate the database access library code. The wrinkle came in that there was no way to split the UML into sections and have it generate database code that referenced tables not in the specific UML diagram. So you ended up with one huge monolithic database library, that took a long time to generate and build, making it painful to make database changes; the alternative was to split the UML into logical sections, but you would lose the database integrity checks, because the tools could not link across diagrams.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
What all of these have in common is a development style that they will tend to enforce on your team. This is not a bad thing, but it is something to be aware of, especially if you are using two or more with styles that conflict, or any that conflict with the company's process style.
An example of this is most UML products. They tend towards the process-heavy side of the spectrum, and recommend the full Analysis/Requirements/Design/Development/Testing cycle. If you are working in a Agile style, these tools will be a significant deviation from your accustomed process, and you will need to take this into account when shopping for the UML tool.
Another example is Rational Rose. One of the earlier versions was integrated with a relational DB mapping tool called Persistence. You could draw your UML class diagrams in Rose, and drop them into a generator that would generate the files that Persistence would use to generate the database access library code. The wrinkle came in that there was no way to split the UML into sections and have it generate database code that referenced tables not in the specific UML diagram. So you ended up with one huge monolithic database library, that took a long time to generate and build, making it painful to make database changes; the alternative was to split the UML into logical sections, but you would lose the database integrity checks, because the tools could not link across diagrams.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Saturday, February 18, 2006
Thinking Outside the Box
Sometimes you gotta stretch the definition of things...
If you have a new application that needs interprocess communications, but you don't want to build the whole infrastructure, consider using something like email or instant messaging for IPC. Many modern languages have libraries that support email, so it's not a difficult thing to add, and allows you to take advantage of the entire internet connectivity. You also can use it for communications back to developers, when significant errors occur.
Instant messaging can be used as well, but there are fewer libraries built-in to langauges. It's faster and more connection-oriented, but less well-supported across the networks. You will have a variety of IM protocols to choose from, and a plethora of servers to run, should you choose to run a private server.
Another useful hack for developers is to use Gmail as a poor-man's FTP utility. Since you have over 2.5GB of space on an account, it will be large enough for most any transfer. You probably will want to encrypt your files, however, to preserve security. This will pose a slight problem, as Google blocks encrypted archives. Never fear, because you can use something like uuencode to convert an encrypted file into pure ASCII. After downloading the file, uudecode will convert it back into its original binary form.
Andrew Tannenbaum has been quoted as saying "Never underestimate the bandwidth of a station wagon full of tapes shurtling down the highway". As network speeds have increased, so has portable storage density, so the saying is probably as true now as it was then, with only the vehicle and media changing (I'd probably reference a minivan full of USB thumb drives, personally). Sometimes the brute force approach is the best combination of simplicity and utility. If you need to be able to do a rapid upgrade with the ability to just as rapidly return to the initial setup, look into the cost of simply making a complete copy of the machine in the new configuration, and perform the switch by swapping the network connections.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
If you have a new application that needs interprocess communications, but you don't want to build the whole infrastructure, consider using something like email or instant messaging for IPC. Many modern languages have libraries that support email, so it's not a difficult thing to add, and allows you to take advantage of the entire internet connectivity. You also can use it for communications back to developers, when significant errors occur.
Instant messaging can be used as well, but there are fewer libraries built-in to langauges. It's faster and more connection-oriented, but less well-supported across the networks. You will have a variety of IM protocols to choose from, and a plethora of servers to run, should you choose to run a private server.
Another useful hack for developers is to use Gmail as a poor-man's FTP utility. Since you have over 2.5GB of space on an account, it will be large enough for most any transfer. You probably will want to encrypt your files, however, to preserve security. This will pose a slight problem, as Google blocks encrypted archives. Never fear, because you can use something like uuencode to convert an encrypted file into pure ASCII. After downloading the file, uudecode will convert it back into its original binary form.
Andrew Tannenbaum has been quoted as saying "Never underestimate the bandwidth of a station wagon full of tapes shurtling down the highway". As network speeds have increased, so has portable storage density, so the saying is probably as true now as it was then, with only the vehicle and media changing (I'd probably reference a minivan full of USB thumb drives, personally). Sometimes the brute force approach is the best combination of simplicity and utility. If you need to be able to do a rapid upgrade with the ability to just as rapidly return to the initial setup, look into the cost of simply making a complete copy of the machine in the new configuration, and perform the switch by swapping the network connections.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Friday, February 17, 2006
How Not To Be Seen
It's relatively rare these days to be part of a team that is just forming. Most of us start a new job with a bunch of existing developers already working on the product. So there is a period of adjustment as you learn the new team's process and culture.
One of the worst things to do during this time is to start commenting on the team's practices in a critcal manner, even if they are suboptimal. This will not endear you to your new colleagues.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
One of the worst things to do during this time is to start commenting on the team's practices in a critcal manner, even if they are suboptimal. This will not endear you to your new colleagues.
- Don't assume that they are not reading current journals. If they are not taking advantage of the latest technology, it may not be because they haven't heard of it.
- Don't act surprised if they don't have all of the Best Practices implemented. Company politics, inertia, and scheduling may prevent them from implementing them
- Don't try to impose your favorite practice. You will appear arrogant. No matter how good an idea it is, you will piss people off.
- If you really wish to change, build support from within. No group welcomes an outsider trying to change things by fiat.
- Don't go running to the manager to get things done without first. It looks to coworkers like you can't support your idea, and want to short-circuit the team's evaluation of the idea.
- Never talk about how great the process was at your last job. The team has had to work under this company's system, and they are probably making the best of it here.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Monday, February 13, 2006
Hints for new programmers - someone else's view
I was poking about today and happend across this article about what advice to give a new programmer. Overall, I agree with it, except for the parts about a coding standard, Singletons, and comments.
Singletons are more than just global variables. Even if you code them to just be wrappers around global variables, you've gained some encapsulation, and that will help you when you need to track changes to something global - you put a trace statement into the set function for the value, and you'll see where it's getting changed.
A single coding standard is important - the article shows a small function with 2 different styles and states that it's easy to work out the code flow and intent. Well, sure it is, when you've got only 5 lines of code. Where a coding standard shines is in functions that are longer, with more complex interactions. I had the misfortune to be looking at some code recently that as far as I can tell had been developed by at least 3 different people, each with a different indentation setting and brace style. I found differences in one function (about 30 lines) in intertwined sections of the code. Following the logic was difficult because I had to keep going back to the start of each clause to see if I was exiting a layer. If you can't get your development team to agree on a standard, enforce one with an automated tool - you will be thankful later.
And finally, comments. The article does recommend using comments for the WHY and not the WHAT, and rightly ridicules commenting each change in the top of the file, but if you don't comment on the why of each non-obvoius path in the code, the developers that come after will miss it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Singletons are more than just global variables. Even if you code them to just be wrappers around global variables, you've gained some encapsulation, and that will help you when you need to track changes to something global - you put a trace statement into the set function for the value, and you'll see where it's getting changed.
A single coding standard is important - the article shows a small function with 2 different styles and states that it's easy to work out the code flow and intent. Well, sure it is, when you've got only 5 lines of code. Where a coding standard shines is in functions that are longer, with more complex interactions. I had the misfortune to be looking at some code recently that as far as I can tell had been developed by at least 3 different people, each with a different indentation setting and brace style. I found differences in one function (about 30 lines) in intertwined sections of the code. Following the logic was difficult because I had to keep going back to the start of each clause to see if I was exiting a layer. If you can't get your development team to agree on a standard, enforce one with an automated tool - you will be thankful later.
And finally, comments. The article does recommend using comments for the WHY and not the WHAT, and rightly ridicules commenting each change in the top of the file, but if you don't comment on the why of each non-obvoius path in the code, the developers that come after will miss it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
Subscribe to:
Posts (Atom)