Posts Tagged ‘developer’

I was reading an article in Information Weekly by Michael Biddick while waiting in a recruiter’s lobby. In it, he provides statistics on how important SaaS has become to organization, and the reasons behind the uprise: speed, cost.

It certainly is a movement that was predicted with web services, WSDL/SOA, WCF, and cloud computing in terms of technological evolution, but what about employment. Will this mean software developers and engineers may become employed by more software companies who provide these services? Will this result in fewer in-house IT positions? Or will many of the IT positons that become available be more concerned with security – the primary concern of SaaS implementers?

I’m personally looking forward to the free hard drive space and memory when the online version of Microsoft Office is released this year, and find it ironic that it was precisely those monstrous software packages which forced our systems to require GIGS of memory and hard drive space. In this instance, it feels like Microsoft is selling the big house it built to raise the kids and moving to some place tropical. If software is leaving the company system, if software developers are migrating to software companies, it will be interesting to see what we do with the space.


Read Full Post »

My ideal work day as a software developer would go something like this:

  1. I grab breakfast. During my breakfast, I transition from domestic life to work life.
  2. I go to work. When I arrive, I grab some coffee. It’s good coffee.
  3. While drinking the coffee, I have a conversation or two with people, some outside of my department, some inside. Maybe I even attend a weekly morning meeting and thumb through a catalog or magazine while I listen to the stakeholders discuss the health of my company.
  4. I head to my office and close the door.
  5. I spend the next hour checking out Visual Studio 2010, or reading an article, maybe a code example. This is more than likely information not directly related to the work I do.
  6. I attend a team meeting or Scrum. I don’t necessarily dig it, but during the meeting, I’m able to make a suggestion to someone with an obstacle. So that’s pretty cool.
  7. I return to my desk and pull up the tasks assigned to me.
  8. For the first task, I pull up the related use case. I read the user story and have a good understanding of how what I’m working on integrates with the system. I have a couple questions about the Normal Flow.
  9. I walk down the hall and have a converstion with a business dude and get the answer to my questions.
  10. I go back to my desk and spend he next few hours composing the prototype solution for the use case I’m handling. I start by stubbing it all out, hooking up my data connections, and maybe rolling the Repository. I may stop and scan the internet for some articles on the Repository Pattern just to stay aware of trends in practices, problems, etc.
  11. My daughter calls me. We have a 30-minute conversation about some event coming up at school, how excited she is about her soccer game this weekend, and how her sister can be annoying sometimes.
  12. Nobody gives me crap about my phone conversation, and nobody cares.
  13. I get up and go get a soda.
  14. On the way back to my desk, I notice Bob’s door is open. Bob is the CEO. I ask Bob about a idea he mentioned in the morning meeting. Bob and I talk about it. Bob is genuinely interested in what I have to say. I probably take that for granted.
  15. I go back to my desk and check in what I’ve worked on.
  16. I get in my car and go home.
  17. When I get home, I don’t even look at a computer. In fact, I go out on my balcony to check on my strawberry planter and watch the birds from my hammock.
  18. I do one or more of the following: I pursue a hobby, play music, cook interesting cuisine, read fiction, drink wine from San Luis Obispo, contemplate the dryness of it.
  19. I watch very little news.
  20. I do engaging things with my family members.
  21. I attend a speech club. I make a speech.
  22. I go to bed. I dream about pleasant things.
  23. The next day, I do it again. Nobody is expecting me to arrive at work with a volume of new knowledge I gained by spending my evening engrossed in something that causes me to lose sleep.
  24. I’m rested, at peace, progressing, and contributing. I have friends. And my family/kids don’t hate me for being a workaholic.
  25. What is your ideal day?

    Read Full Post »

In Chapter 1 of Alistair Cockburn’s “Writing Effective Use Cases,” which I have to believe is the book most often recommended when someone is seeking to learn about use cases, we are first presented with a few questions, the second of which really captures the tone of the tome, and frames what I’d like to discuss today:

“Why do different project teams need different writing styles?”

First and foremost, when I read questions like this, I hear all the upper-management types I’ve dealt with in the past whine the same question: “Ok. First you convinced us that we need to document requirements, and now you’re telling us that there’s going to be some work (a.k.a., money) to determine the style that’s right for our team?” This is, of course, a cup-half-empty perspective on the idea. After all, going through a process that would result in your organization achieving greater communication and efficiency isn’t a bad thing. Documentation alone is a hard sell, especially when budgets are tight (or “in this economy,” which I believe has recently replaced “in bed” as the most popular fortune cookie ender). And you can’t use hollow, stock phrases like “all successful projects start with good requirements.” All the people holding the purse strings hear when you give them that stuff is akin to the teacher from Charlie Brown. So it’s important, as analysts, that we have a pointed reply, something beyond “We’re just going to use the force.”

Step 1 – Identify the Levels.

Thank goodness, Cockburn points out the three levels of detail in writing use cases, which is good, because management likes short lists. If you tried to say “there are ten levels of detail we can use to write use cases,” this would cause wincing and grimacing.
Effective Grimacing

I’m not saying that it’s possible to explain the effectiveness of use cases to that guy. However, what comprises the three levels is as equally important as the fact that there are three. The “brief” use case is the short, one- or two-sentence statement that can fit in a table or spreadsheet. The “casual” use case can be a few summary paragraphs, and the “fully dressed” use case is the most thorough approach.

Step 2 – Identify which to use.
So now that we have presented our short list of methods from a reputable source, we will no doubt need to respond the next obvious question, “Which style do we use?” It doesn’t hurt anyone to take all the Use Cases identified and compose the “brief” style. Obviously this gives you a nice, informative list of work items to which you can append priority, frequency of use, or other tidbits. Whether the brief use case is a candidate for a more verbose explanation via the “casual” style can come down to a couple questions:

1. Have we done this before?
2. Is this a core piece of the project? Either from
a. a development/complexity perspective or
b. the client/customer perspective

If functionality has been developed on similar projects, obviously a very minimal amount of discussion is required to reproduce the same in the new project, so going beyond the basic is probably not warranted. What immediately trumps this for me is if either the development team or certainly the customer has any concern or gives the use case any weight. The “casual” style is both perfect in name and intent. The word “casual” plays down any notion that you’re going to go into some deep analysis that requires time and money, and yet you give the use case the treatment it deserves to create the communication baseline.

Last, but certainly not least, the “fully-dressed” use case. I like to think of these as “black tie” use cases.
Black Tie Use Cases

Here, we’re really thorough and detailed and maybe even looking for a degree of polish, as we would if dressing to go to the ballet or a dinner party. This method is called for if both the client and development team consider the functionality to be core to the product. Even if the functionality has been developed before on a previous project, if it is core to the new product, a full treatment is required because the core usefulness of the feature is directly tied to the client brand. If I can’t take money out of the ATM machine, the bank name suffers. In addition, fully dressing the core functions allows the uniqueness of the particular client/customer to come to the surface. It works like salt and pepper work to enhance natural flavors. Just like with ATMs, each bank has a different flavor on the same function based, at least in part, on their branding which leaves you with the ability to favor one over the other. So, functionality that represents a point of market competition, and thus a major business objective, must be fully dressed. I also use a metric to govern whether the use case needs the full treatment, such as if three or more questions arise from any stakeholder.

So that’s a two-step procedure for selling the idea of using use case analysis for projects to those in power. Two steps! Golly jeepers that’s easy! Here’s the kicker: the discovery process happens whether realized or not. Project teams, in order to achieve their highest degree of efficiency and productivity, require a discovery process to find the methods of requirements documentation that work best. This can either be recognized or not. It’s a matter of unconscious incompetency or conscious incompetency, not knowing what you don’t know, and knowing what you don’t know. Those companies that proactively engage in the process become successful, productive, and fun places to work. Those same companies have either established analysts or analyst consultants as key contributors. These people can also effectively throttle the amount of requirements practices exposed to a particular team. The result is you either have companies who understand the complexities before the project at an appropriate level, or are reflecting on them in the same – albeit more excruciating – detail as they close their doors forever.

Read Full Post »

Information Technology has reached the finish line. You can’t write code that hasn’t been written before. You can’t develop software that I can’t buy. The focus of IT on social networking results in nothing more than the same advertising sales that brought Yahoo! to stock market prominence, eventually becoming Google’s dominance, but is predicated entirely on our need to see an advertisement in order to consume a good or service. Great! Now we can all talk to each other, and we don’t have to use the phonebook, or even a phone.

What is IT able to do to now to actually further global progress? DNA analysis? And how many job slots are available for that purpose? Has IT reached a massive finish line and is that why so many of us are seeking opportunities now? What does the world need now?

Let me know. In the middle of this gloomy economy (and a matching weather pattern in Cincinnati at least), are you actually working on something NEW?

Read Full Post »

The average salary for a project manager is $96,000. The average salary for a senior application developer is $85,000. If a person is hired to do both jobs, does that person get a salary of $171,000? No. It’s a cost-cutting tactic, and in this market it’s easy to find a person willing to do anything or say they can do anything to get that job slot. We are asking our work force to be jacks of all trades, and master of none. As a result of our cutting, we really cut the “it” – the essential ingredient – out of IT.

Real-world Job Titles
• Applications Systems Analyst/Programmer
• Programmer Analyst Consultant
• Database Application Developer

Look at the job titles I’ve listed. Although the first two scream “multiple-hats,” you’re probably thinking “Database Application Developer” is a straightforward title, so you’ll be perplexed to learn that when I asked some colleagues to read the description of the job that accompanied it, when faced with three choices, “Project Manager”, “Systems Analyst”, and the actual title, most chose “Project Manager.”

So to save cost, we’ve begun to place more responsibility on a single person. If you give me three things to do, like develop computer code, analyze and define requirements, and maybe even help manage the expectations of a client, I may do all of those things pretty well. But if you let me come to work, spend an hour of my 8 learning, and then focusing on doing one thing, the breadth and depth of what I’m able to accomplish will increase dramatically. Back in the day of the Internet boom, I was typically encouraged by my boss to learn and read. In fact, that’s how I got into IT in the first place. The VP of the company I was working for walked up to me with a manual and said, “learn this.” But all I’ve heard for the past 5 years is “get it done.” And worse, only one opinion has started to matter when designing solutions, usually one based on position or title, and that title, unfortunately, isn’t often “customer.”

We’ve taken our eyes off the ball and fixated it closely on the dollar. Many of us probably believe the dollar is the ball. Who can blame us? Everyone is busy convincing each other that monetary shortage is the issue. But let me invite you back into the batter’s box, get your mind off the scoreboard, and retrain your eye to that hanging curveball:

“The cure for Apple is not cost-cutting. The cure for Apple is to innovate its way out of its current predicament.” – Steve Jobs

The average salary for a junior programmer, fresh out of college, is $53,000. These are young, energetic people who ideally have the latest information and a lot of confidence, perhaps too much. Do we want these people to stop learning when they leave campus? The two sentences above contain two key concepts: cost-cutting and innovation. Which do we want our freshest, brightest minds to encounter? Do we simply want them to “get it done” for $53,000?

“Learning and innovation go hand in hand. The arrogance of success is to think that what you did yesterday will be sufficient for tomorrow.” – William Pollard

Innovation happens when a situation exists such that all ideas are welcome, but funneled and filtered through a guided alignment with business objectives. If you’ve got 20 developers focused on one idea and one goal constantly, innovation is dead. If those same developers get a half hour each morning to explore their solution domain – read articles, work through examples, explore new techniques – you end up with a team of well-informed people that can approach a problem collectively with greater breadth, with genuine excitement and positive attitude, and readiness to find a solution. But if they and their managers spend their morning trying to fill multiple roles, that energy is stifled. The result is a cost to the business. If you ask a programmer to be an analyst, you’re likely getting half the programmer and half the analyst. You’re also getting someone less likely to proactively contribute to the mission, and less likely to achieve a sense of ownership toward the company. I’ve seen so many developers become team leads or managers with nothing more than a modest increase or a title change. They soon learn the price of such cost-cutting. Well guess what?

“The cure for the United States is not cost-cutting. The cure for the United States is to innovate its way out of its current predicament.” – Cliff Adams (with a lot of help from Steve Jobs)

Copyright (C) 2009 Adams Enterprises, LLC

Read Full Post »