What an easy request. Right? Just change the CSS to display:inline. An easy fix. In fact what could be easier?
Well maybe not so easy. What if that button does nothing until certain criteria are met (which is why it was hidden)? Often users do not understand that cosmetic changes have functional implications. Worse than that, changes are often made to design without asking about the functional implications.
For example, "What does it mean that this button is visible?","What now happens if someone clicks on a button which shouldn't be clicked under these cirsumstances?", "Should we throw an alert error?","How about an inline error?"
Why should you show a button which cannot by definition of the current spec even do anything at this point in time?
It is getting to the point where I just say "Yes".
Wednesday, September 2, 2009
Creating solutions to non-existent problems
People love Excel. People hate Excel.
People want a solution which is not Excel. Let's face it, there is very little color aside from green. It is a pain to format cells. It gets boring. We had hoped to move on by using Powerpoint for everything, but we can't expect a painter to do the job of an engineer. So what do we do?
We ask for a custom applications to be built. AHA! We will escape the doldrums of empty cells. We will have buttons, and color, and, and...well what do you have?
If your business process is to manipulate large swaths of data, data that can be altered by a large group of people seldom at the same time, perhaps Excel isn't so bad.
"Time to get to the point," you say? It is simply this: If there is a problem with a business process, creating custom applications is not going to help. If you are tied down by the randomness of excel manipulations and want to have some structure to your process, you can't then demand the ability to use Excel. Excel solves certain types of issues. If it is inadequate, that's fine. It often is. But the alternative is not to complicate the randomness of Excel with the restrictions of a custom application. Applications are built according to processes and workflows, something that is inherently missing from Excel.
In those cases where custom Excel addons are created or custom workbook templates are created, the business process is well defined before development begins. Specs change, features grow, but the over reaching arc should remain consistent.
Most users do not understand this. But if the converse were true well, you wouldn't have any users. A simple example would be selling someone an application in development that would cure cancer, but when you actually delivered the product it ended up making ice cream. It is the same project, but through lack of thoroughness and direction, the outcome varied vastly from the initial proposal.
Since user have little idea of the process of software development it is hard for them to see their little changes as having big impacts. Even in non-coupled, highly modularized code this is an issue if now the separate components are logically contradictory.
People want a solution which is not Excel. Let's face it, there is very little color aside from green. It is a pain to format cells. It gets boring. We had hoped to move on by using Powerpoint for everything, but we can't expect a painter to do the job of an engineer. So what do we do?
We ask for a custom applications to be built. AHA! We will escape the doldrums of empty cells. We will have buttons, and color, and, and...well what do you have?
If your business process is to manipulate large swaths of data, data that can be altered by a large group of people seldom at the same time, perhaps Excel isn't so bad.
"Time to get to the point," you say? It is simply this: If there is a problem with a business process, creating custom applications is not going to help. If you are tied down by the randomness of excel manipulations and want to have some structure to your process, you can't then demand the ability to use Excel. Excel solves certain types of issues. If it is inadequate, that's fine. It often is. But the alternative is not to complicate the randomness of Excel with the restrictions of a custom application. Applications are built according to processes and workflows, something that is inherently missing from Excel.
In those cases where custom Excel addons are created or custom workbook templates are created, the business process is well defined before development begins. Specs change, features grow, but the over reaching arc should remain consistent.
Most users do not understand this. But if the converse were true well, you wouldn't have any users. A simple example would be selling someone an application in development that would cure cancer, but when you actually delivered the product it ended up making ice cream. It is the same project, but through lack of thoroughness and direction, the outcome varied vastly from the initial proposal.
Since user have little idea of the process of software development it is hard for them to see their little changes as having big impacts. Even in non-coupled, highly modularized code this is an issue if now the separate components are logically contradictory.
Outsourcing interpretation
You would think spending two weeks in india would really fill me with the desire to blog aoubt my experiences. Both here and my non-work related blog. Surprisingly, two weeks in a foreign country didn't have the impact one might think. But since my return one constant thought has been stuck with me.
As much as software development cannot be compared to assembly line production, outsourcing development cannot be compared to manufacturing outsourcing.
Maybe more on this. I don't know.
As much as software development cannot be compared to assembly line production, outsourcing development cannot be compared to manufacturing outsourcing.
Maybe more on this. I don't know.
Wednesday, April 8, 2009
C# and Xml Literals
How do you use XML Literals with C#?
You don't.
You choose a language based on history, need, efficacy, etc. Not just because you feel like it.
You don't.
You choose a language based on history, need, efficacy, etc. Not just because you feel like it.
Tuesday, April 7, 2009
And Boom.....
So I learned today that from now we will no longer code in vb.net and all new projects will be in c#. Why? Well. Because, that's why.
Thursday, April 2, 2009
God is an agile developer
One thing that greatly bothers me in my current position is that no matter how much work I do each day, nothing is ever accomplished. Every project is kept in perpetual development and feature creep is more common than well...anything that is very common. I code. I honestly do. This is why I haven't written much lately. I have been head down barreling forward. Today I have a reprieve. And I also have feature creep.
First of all I am no starry-eyed dream and I realize that feature creep is to be expected in any project. In fact it should be planned for. For most applications there is neither the time nor the knowledge to flush out every possible area of development. However, planning feature creep should be differentiated from scope and purpose changes. Feature creep should be seen as a way to maintain the vitality of an application while also maintaining its core purpose. If the purpose of an application needs to change, a new project should be rededicated. Salvage what code you can and start over. Sometimes it is easier to jump into the sea than to change the course of a sinking ship. This is because feature creep often devolves into a change in the scope of the application itself, often rendering initial planning moot. Design often follows purpose, even if loosely. So such a change can destroy the initial premises of the design of your application. Of course this may not be the case which is why good employees should be not being let out the door. Thoughtful developers will take the time to decide to salvage or ditch.
Feature creep does not have to be a bad thing if it is incremental and time is allowed for each iteration to run its course. However, feature creep becomes detrimental when it becomes a hindrance to the release of the software. Often at my company, each iteration of a feature results in modification of that feature and the addition of new features. This happens in a purely development, sometimes theoretical place. Unfortunately the view of software is in its totality. Only the perfect idea of the software can be released. This waiting for perfection often adds two things to the project - an invisible deadline and failure.
The deadline vanishes since each new request pushes the software date out further and further. Failure then arises from the inevitable waterfall approach that ends up becoming the de facto development model. So much time goes between project launch and project end that several things happen:
1 - People wonder why this software took so long when it seems so simple
2 - People wonder why things do not behave exactly as they expect
The longer a project goes without business user mediation, the more likely it is that the same users will forget why they have asked for something as well as forget how much they asked for.
What becomes necessary and what becomes auxiliary is blurred since now both are merged into this one application. Unfortunately there is no way to get this time back. Everyone is unhappy and nothing gets done.
Oh and the title? Read the creation story in the bible, if you still don't get it. I can't help you.
First of all I am no starry-eyed dream and I realize that feature creep is to be expected in any project. In fact it should be planned for. For most applications there is neither the time nor the knowledge to flush out every possible area of development. However, planning feature creep should be differentiated from scope and purpose changes. Feature creep should be seen as a way to maintain the vitality of an application while also maintaining its core purpose. If the purpose of an application needs to change, a new project should be rededicated. Salvage what code you can and start over. Sometimes it is easier to jump into the sea than to change the course of a sinking ship. This is because feature creep often devolves into a change in the scope of the application itself, often rendering initial planning moot. Design often follows purpose, even if loosely. So such a change can destroy the initial premises of the design of your application. Of course this may not be the case which is why good employees should be not being let out the door. Thoughtful developers will take the time to decide to salvage or ditch.
Feature creep does not have to be a bad thing if it is incremental and time is allowed for each iteration to run its course. However, feature creep becomes detrimental when it becomes a hindrance to the release of the software. Often at my company, each iteration of a feature results in modification of that feature and the addition of new features. This happens in a purely development, sometimes theoretical place. Unfortunately the view of software is in its totality. Only the perfect idea of the software can be released. This waiting for perfection often adds two things to the project - an invisible deadline and failure.
The deadline vanishes since each new request pushes the software date out further and further. Failure then arises from the inevitable waterfall approach that ends up becoming the de facto development model. So much time goes between project launch and project end that several things happen:
1 - People wonder why this software took so long when it seems so simple
2 - People wonder why things do not behave exactly as they expect
The longer a project goes without business user mediation, the more likely it is that the same users will forget why they have asked for something as well as forget how much they asked for.
What becomes necessary and what becomes auxiliary is blurred since now both are merged into this one application. Unfortunately there is no way to get this time back. Everyone is unhappy and nothing gets done.
Oh and the title? Read the creation story in the bible, if you still don't get it. I can't help you.
Subscribe to:
Posts (Atom)