Tuesday, December 14, 2004
Monday, December 06, 2004
I have had some experience working with Mercury Test Director. SWAT worked with my project team on my last project, and they recommended Mercury. On that project, we even had automated tests (although I am still not sure what percentage of our test cases ended up as automated tests). I thought Mercury was okay, but for that project we did not use the web version of issue tracking, and I thought it was a real bugger noting my issues in notepad until I got into the office the next day.
My current project is using the issue list in SharePoint as our issue tracking. While this solution is a good enough solution, it would be nice if my fellow team members could see all of thier issues at once from multiple projects. Sure, we could have set up one wss team site to handle all issues, but I don't think SharePoint security would effectively manage who can add issues to which project and who can see which issues, and so on.
So for a smaller consulting company, what is the best solution to issue tracking? I am not sure the complexity of Mercury would be a good fit (or the price tag). SharePoint really isn't meant for full-fledged issue tracking for a corporation. A custom solution would be fun to build, but I am not sure the amount of time we would have to invest would be worth it.
I did a little research, and although I am often annoyed at the lack of pricing information on product sites, here are some that look interesting:
So have you used any of these tools? Anybody have any reviews to contribute or any other tools to add?
BTW - Thanks to David Hayden for his blog posting about Gemini. I ran into a bunch of open source issue tracking tools (like Bugzilla), but had trouble finding a free .Net issue tracking tool.
Tuesday, November 30, 2004
So has anyone else used ORM instead of an ER diagram for database design? What do you think about ORM? Will you leave ER diagrams in the dust?
Monday, November 29, 2004
This topic has been hot for the past number of years, and I think I fall in the minority when I say that I am not against outsourcing to India if the market in India can produce the same quality software products that are being produced here at a fraction of the cost.
I am not saying that I hope to have my job outsourced to India. What I am saying is that in a world where I believe in free markets, when competing for business, the company that can offer a product or service of equitable quality at the lowest price should win the business.
If I am unable to compete with the engineers from India, should I be angry with disloyal American companies who outsourcing? If my salary is much higher here than it would be were I living in India, should I fight for laws to prevent money from flowing out of our economy and into another? As a local consultant, am I offering services that can be easily replaced with foreign labor? Should I, instead of trying to stop open competition, figure out a way to offer a service to US companies that cannot be outsourced?
And if the implementation of a design spec can be outsourced, can the initial analysis also be outsourced? How about the project management? Are there things that we, as software engineers living in the United States, can offer that cannot be outsourced? Should we, as an engineering community, focus on growing our unique skills and ensuring our place in the world market?
So the question is this: can India offer the same quality software end-product that a local consulting company can offer at a lower price? I am leery of the possibility because on the projects in which I work, constant communication with my customer is paramount to success. I wonder how the communication barrier is overcome when dealing with an implementation team that lives in another culture. I am curious if anyone out there has experiences, good or bad, with outsourcing software engineering to India.
Monday, November 22, 2004
I have heard of companies that use titles in lieu of paying their talent well. "We cannot afford a large raise for you this year, but how about we give you this fancy title of 'Senior What-a-ma-bob'." So what is the point of a title? Do titles help define our skill set? Do titles help communicate our level of excellence? Or are titles a way for management to placate us into feeling important without giving us monetary reward? What if we did away with titles all together?
Wednesday, November 17, 2004
As some years have passed, or maybe as my employer has changed, the agile methods have really seemed to catch on. Iterative approached are being tested, and in my experience they are successful. I do not claim to be a guru on agile methods, and I do not claim to know the ins and outs of SCRUM versus Extreme Programming. But what is the key difference between the agile methods versus the traditional methods to software engineering?
I think the difference can be summed up in one word: communication.
While communication has always been an important part of software engineering, I fell that the traditional approaches encourage us to lay everything on the table from the start. Go through a phase of requirements gathering. Go through a phase of specification writing. Go through a phase of writing a detailed design document. Finally, build what you planned. Plan your work and work you plan, right?
I say wrong! To me, the key to the success of the agile projects I have worked with lay our ability as a development team to admit that we cannot ask all of the questions up front. Besides the fact that requirements change with time, so does our understanding of the business problems. And I have never seen a requirements document that is not laden with holes and ambiguities. A small detail missed in the requirements phase can be the downfall of the entire project.
Agile methods appreciate this risk and mitigate it through constant communication. There is no one phase where meetings are held with the end users. The end users are involved in meetings with the development team throughout the life of the project. The end users are part of the team and play an active role in communicating with the development team and working with the seeds of the end product from its infancy to its completion.
As a result of my experiences, I hope to never spend a year working on a functional specification again. I hope to never face another deployment phase of a project that follows a year of closed-door development. I hope to say goodbye to the waterfall approach once and for all and hello to agile development.
Wednesday, November 10, 2004
While I do believe that education is important, I believe that education can come in the form of reading books, working, traveling, and just living life in general. Albert Einstein was a high school drop-out (okay, later in life he squeeked his way past earning a degree) who wrote his amazing papers without any academic instruction while working as a patent clerk. He hated the rigid structure of the classroom setting.
So in my estimation, a person's worth should be measured by their ability to present themselves, by their passion, and basically by their performance rather than by a piece of paper signifying their diligence to show up to and pass college level courses. Don't get me wrong, you can get a lot out of college. You can also get very little.
Has anyone else come across a similar problem? Has anyone installed the hot fix? Has anyone fixed this issue by getting rid of the solution file and only using file references?
Thursday, November 04, 2004
When people started programming in DOS instead of using punch cards, I bet some people were up in arms. I wonder if the argument flew around that real engineers did not use DOS. Where is the discipline in DOS? Anybody can write programs in DOS, it takes someone with training and superior intelligence to program on punch cards! Look at all these rag-tag new-fangled youngsters with no experience hopping right in to the development community!
I also have known people who love notepad. All you need to write a good application is a text editor and a compiler, right? Visual Studio is for sissies, and intellisense is for people who are not careful enough to spell correctly when they are typing and for people who don’t already know which assemblies house which classes.
To that, I say bah!
I think that using visual designers fall right along side using intellisense while coding. If intellisense helps you work faster and cleaner, then I don’t buy the argument that we should experience a certain amount of pain in order to be respected as intelligent software engineers. In my opinion, visual designers sometimes come in handy. I use the visual designers when I would otherwise be writing a bunch of repetitive HTML. I can drag a control onto a page and position it with a click. In short, tools such as the visual designer can help me with simple and repetitive tasks and leave me more time to focus on my programming logic.
Monday, November 01, 2004
When the design was solidified and approved by the client, the implementation phase was next. Our implementation phase was followed by deployment, and we were paid and the project was wrapped (theortetically) when the client gave us final sign off by agreeing to and walking through the user-acceptance tests to validate that each requirement was met and user interface was bug-free.
Nowadays I find myself working with agile approaches to software development, but I do still find value in client testing. I am not talking about handing the product over to the client and asking them to start using it. I am talking about creating some test scripts to help the users cover each logical path in the application, and building validation testing into the scripts. Since my company does not have a test team, I recently took a stab at writing a test script myself. How do the rest of you do this? Do you rely on the use cases that are created during design as your test scripts? Do you use an automated testing tool alone to test the user interface, or do you use an automated tool in conjunction with user-acceptance testing? Is user-acceptance testing out-dated?
Wednesday, October 27, 2004
The time is t - 12 and counting. I am sure you have all been there. You have planned out all of the tasks. You have worked hard to meet the deadline. You felt in control of the iteration. You knew you had this one nailed. But then, as the hour of deployment draws near, it seems like a cruel trick has been played. Suddenly there is an insurmountable amount of work left. Are the tasks multiplying? It seems like as each loose end is tied up, two new ones pop up as if some evil magic spell were cast on the project. It is in this hour, when the odds sometimes seem overwhelming, when I am beginning to forget what the outside world looks like from the long hours of staring at my laptop screen in my cubicle, when the pressure is on, that somehow I feel that I do my best work. Am I a masochist? I have decided that either I perform well under pressure, or I am delirious from a lack of sleep. Do you know the feeling? Where after staring at a problem for hours the solution appears to you so clearly it is as if it were the result of pure genius and you feel completely satisfied with the world…then again, maybe even a hack looks like an ingenious solution when time is short.
Tuesday, October 26, 2004
Monday, October 25, 2004
Let’s take architecture, for example. When architecting a solution, there are many roads I could take. I could spend 5 minutes on the architecture and hop right into the code. I could spend weeks on the architecture, fashioning a framework made of steel, a framework where I have abstracted every piece that may be shared, a framework where I have carefully planned the separation of the data layer from my domain layer so my customers could use XML, Oracle, or SQL Server as the data store by just changing a setting, and a framework where my domain layer never relies on a configuration file that is specific to a web front end. The more flexible my framework is, the more time that must be spent planning and executing.
The time spent planning a flexible architecture should pay for itself in the long run, when it comes to time spent maintaining and extending the solution. But what if my customer never wants to change data stores? What if my customer only wants to deploy a web solution? How do we determine when the payoffs from planning flexibility are no longer worth it? Can we plan so much that we are gold plating our architecture?
Thursday, October 21, 2004
Java, on the other hand, has a much shorter history. Java was born in the early 90's. By this time, OO techniques were really catching on. It is not surprising that OO concepts were included in the implementation of Java.
While the first object oriented paper was published in 1965, OO did not become widely accepted by the development community until well after the first release of Basic, into the late 80's. In response to OO programming, and possibly in response to the success of Java, Microsoft redesigned the Visual Studio platform into the .Net release that we have today. My question is this: In rewritting Basic into Visual Basic, and eventually into Visual Basic .Net, has Microsoft enhanced an easy-to-learn programming language into a powerful OO tool? Or has Microsoft been trying to fit a square peg into a round hole?
Wednesday, October 20, 2004
I worked for 5 years programming in VB. I struggled with ASP for awhile, too. So when the alpha release of Visual Studio .Net came out, I couldn't wait to get my hands on it. VB.Net was a change from VB 6.0, but I didn't find the move to be too painful. ASP.Net was like heaven compared to the previous version of ASP. I was excited to leave VB Script in the dust and have a full version of VB at my fingertips when building web apps. And the automated state handling in ASP.Net was another leap ahead for me. I have been working with Visual Studio.Net ever since, and I have never missed the days of Visual InterDev or Visual Studio 6.0.
When VS.Net was released, so was this new language written by Microsoft called C#. Within my VB community, C# was dismissed as a Java-wannabe. Since Microsoft has pledged to back VB.Net, we saw no reason to change. All the curly brackets and semi-colons gave me the shivers, anyways.
So last February when I decided to move to a new company, and my new company is a C# firm, I swallowed hard and cringed as I embarked on my adoption of the curly brackets, case sensitivity, and semi-colons. Thus was born Val the C# Gal. Although there are some syntax differences that take time to become accustomed, it has not been a big deal at all. I have not seen anything huge in C# that was missing in VB.Net and vice versa. What I have noticed, however, is that the mentality of the C# group is quite elitist. So why is that? Why do C# programmers so vehemently disregard VB.Net as a viable language? Why do C# programmers so quickly dismiss VB programmers as somehow inferior in intelligence?
I have worked with amazingly brilliant engineers on both sides, and I don't understand why the C# community feels that if someone chooses to continue crafting code in VB rather than porting over to the C# side of the tracks that the VB engineer is lesser for the decision. How do you feel about this?