What is a Software Developer?

June 26, 2009

In his book Professional Software Development, Steve McConnell quotes someone he interviewed for a development position who answered the question “What is a software developer?” as follows: “During software design, I’m an architect. When I’m designing the user interface, I’m an artist. During construction, I’m a craftsman. And during unit testing, I’m one mean son of a bitch!” Truer words could not be spoken!

What does it take to be a developer in today’s world? Is this person that Steve McConnell quoted correct?

I think so. So let's take a look at a developer as an artist, architect, and craftsman, ignoring anyone being mean and ornery.

Developer as Artist
An essential aspect of software design is the user interface – the mechanism for user to interact with the software. Crafting a good user interface takes time and considerable thought and effort. Many software companies do in fact employ “artsy-types” to help create an attractive user interface.

For those that don’t, there is usually someone geared towards keeping abreast of research dedicated to the “user experience,” focusing on crafting a consistent, intuitive user interface that supports the business goals that the users want to achieve with the software.

One way of designing an interface is through a technique called “paper prototyping.” This is a process of laying out screens, determining what controls are on the screen, how the user will flow through the individual screens on paper. This is far faster and much less expensive than developing the actual screen and seeing if users like it.

Whatever means is used to define the user interface, it is definitely NOT a paint-by-numbers exercise! It takes considerable thought and effort to create an aesthetically pleasing, efficient and effective, ultimately delightful experience. Any many times, you ball up your paper and try again!

Developer as Architect
In the software world, there is a job title referred to as “software architect.” What is a software architect, and what does a software architect do?

A software architect focuses on developing a sound technical framework that other developers can work from. They focus on the layers of the system, the components required and the interfaces needed in order for a system to function; they don’t get into the nitty-gritty details of each and every component, but instead focus on the larger picture.

A good software architect is typically someone who can function as both a technologist and consultant. This dual role is necessary because a software architect will be involved in a variety of people: customers, management, developers, and project managers, to name a few. This means that a software architect must have solid technical and communication skills.

Developer as Craftsman
Developers must take all the inputs – business and technical requirements, the architectural design– and write code to pull all of this together in a meaningful way. In doing so, they must satisfy multiple audiences: other developers and the business users.

The code that they write must be reliable and maintainable; meaning that they or someone else should be able to look at the code at some point in the future, understand it, and update it. And of course, the business users must be satisfied that they can run their business on the software.

While the software architect tends to design in the large, what design work do developers perform? They focus on the design of component internals: the algorithms, data structures, and the organization of the code. Good software design organizes the internals of the components so that they will all work in harmony and in accordance with the high-level architecture, without duplication of code to perform similar functions.

Is there a prescribed method for writing software that can guarantee success? Writing reliable, usable, maintainable code requires that a developer to draw upon prior experience, guidance from others, tools and libraries, ultimately combining these into a concise, logical expression. In reality, there are no guarantees, but there are ways to reduce and manage risk.

Developers write software in specific programming languages. It is relatively simple to determine that a developer who focuses on one language versus many languages will have more depth and expertise in that language. As developers become proficient in the constructs and idiosyncrasies of a particular language, their code becomes clearer and more organized, leveraging the capabilities and recognizing any limitations of the language.

Not all that long ago, a developer writing a Windows® application had to know much more about the underlying operating system than he or she does today. Today, a lot of this “plumbing” code is handled through libraries; and while there is an investment in time required to understand what is available to leverage in these libraries, the benefit is that a developer is leveraged already written and tested code – increasing the reliability of the application.

Another mechanism used to reduce risk is through the use of something known as “patterns.” As those in the software industry encounters the same type of problem over and over again, the prescribed means for handling that problem is captured in a general way, providing guidance in terms of accepted rules and approaches for handling that problem.

This makes patterns generic, and it remains up to the developer to take a best practice and turn it into working code. Of course, this means that developers must be continually updating their knowledge about available patterns.

Over the years, I’ve personally seen significant differences in how developers approach and implement logic to solve business problems. Despite the guidance and libraries available, at the end of the day, it is up to the developer to weave everything together into a concise expression of logic that reliably supports the business need and is maintainable over time.

This is where developers are truly like craftsman. I’ve had ample opportunity to step through code that other developers have written and I’ve come away either very impressed at times, while at other times I’ve been left scratching my head.

Some developers clearly throw code at the problem until things work and make a mess as a result, while others simply are unable to express their logic are clearly as others. It’s like writing; some people can put words down on paper in ways that are more readable and understandable than others. And on occasion – not often enough – you come across solid code that is expressed so clearly and elegantly it is like looking at a masterpiece.

Which brings us back to a developer being an artist.

Will You Be Commoditized Or Offshored?

June 19, 2009

As I was writing my two posts: Is Commoditized White-Collar Work on the Horizon? and How Commoditized White-Collar Work Will Change the Work Dynamic last month, I was also reading a book by Micheal Lopp titled Managing Humans. (No, not at exactly the same time, I'm not that good!) Towards the end of this book, Micheal addressed the issue of offshoring, providing a process to determine if you are at risk for being offshored.

One observation Micheal offered is obvious, but worth noting. As he puts it, “Outsourcing exists because of the Internet and its ability to shrink the planet.” Technology is a double-edged sword, and it is enabling global competition for almost every job out there.

To determine if you are facing immediate risk for being offshored (and I'll add commoditized, as there is equal potential), Micheal had a “process,” which is really nothing more than a series of questions, a few of which I’ve noted here:
  • How much process is in your job?
  • Can you see a flowchart from where you are sitting right now?
  • Are there big black binders that describe what you do?
  • Are you handed specifications from nameless, faceless designers?
Answering yes to any of these (there are more in the book) means that you could be at risk.

And as I thought about these questions, it occurred to me that Micheal is right. The first question might be troubling to some people. It seems that we’re always looking for the one, complete, efficient software process that solves all of our headaches. And as soon as this occurs, wham! Across the ocean it goes.

What can be done about this? If your work can be well-defined and captured in some way that can be moved, the likelihood of it moving is high. Don’t fight it, recognize it and do one of two things:
  • Compete head-to-head on the open market.
  • Change your game and do things that will increase your personal value proposition and make it more difficult for your job to be offshored.
What direction should you go in to avoid having your job offshored? Micheal has an answer for this as well. I’ll provide one quote: “Interfacing with Humans Pays Big Bucks.” I couldn’t agree more! In fact, a number of posts in this blog are not about process, they are about how to approach the people side of software development, what makes individuals truly successful, teams more efficient, and how to align people and teams with the organization to maximize value.

One final observation from Micheal’s book: We need less people to create widgets and more people who know how to creatively assemble widgets to create viable products. Think about that for a moment. Software as a Service, cloud computing, virtualization, all of these technologies are about managing technology more effectively while making it very available to the masses. Once again, he is 100% correct, in my humble opinion.

I'll take this one step further. Technology is creating another interesting situation. The workforce will spend increasingly more time collaborating, but doing so through technology. This will erode a valuable skill, the art of managing and dealing with people.

Some of us “seasoned” employees have had the opportunity to interact with people directly all day, every day through many years. The next generation is not as accustomed to this, nor do they want to work this way. It will take the next generation longer to learn and understand the intricacies of managing and motivating people. This skill will be important and in short supply.

To close, I found Micheal Lopp’s book Managing Humans to be an entertaining, insightful read. I thoroughly enjoyed the book, and as a result I’ve added Micheal’s blog to my blogroll. He writes under the nom de plume “Rands.” I encourage anyone interested in the human side of software management to read this book and check out his blog.

The Perfect Office Setting

June 12, 2009

What is your idea of a perfect office setting? While I’m sure that everyone has their own personal concept in mind, I’ll bet that no one would choose the most prevalent model in place today: the square cubicle.

Square cubicles are a relic of an outmoded era of management and approach to work. When I began my professional career, a person’s status and rank within the organization was always defined by the size of their cubicle. And the work, among other things, flowed downhill in those days as well. In fact, the work was passed down some rather significant – if not bloated – hierarchies.

In my early days of working in a very hierarchical organization, I always took care to operate within the bounds of my position. Whenever an issue arose that required the attention of someone further up the food chain, I always took care to pass the issue along. And that person would always be willing and receptive to take action. It was ordered existence, command-and-control all the way.

Times have changed. We’ve been implementing technology to ratchet productivity up, and we’ve also got a couple decades of “doing more with less” behind us. I don’t know what your thoughts are, but I don’t believe that technology has closed the gap as much as we’ve added to people’s daily workload.

Thanks to the trimming of overhead and flattening of hierarchies designed to reduce costs and optimize speed and productivity, people not only expected to do more, they are also expected to take more initiative and responsibility. And let’s not forget, we have to keep our eye on other things that we never used to worry about, like our 401Ks.

Today, we need to move towards more open, team-based workplaces. Office settings need to address the needs of the new workforce. People need to come together quickly to work on projects in a collaborative environment, adapting space to meet the team’s needs. And because pressure to perform in short time frames will NOT go away, the space should lend itself to enhancing people’s ability to collaborate, and not be an obstacle to it.

Most of the standard cubicle layouts in use today actually impede collaborative efforts. They are too cramped, too closed in, and end up stifling teamwork. Here’s a telling question: Do you feel more comfortable working at the corner coffee shop, or your office?

If you answered the coffee shop, why is this so? Frankly, most office layouts are archaic. They assume everyone will come to work every day and toil on personal, isolated projects. And when people do need to meet, conference rooms are available, which again are based around information-sharing needs and discussion purposes, not team collaboration.

A more relaxed coffee shop atmosphere with comfortable chairs, tables, white boards, open meeting areas with large screens would be, well, fun, wouldn’t it? Given the stress to deliver that we’re all under these days, shouldn’t an office reflect the desire for more relaxed, innovative, collaborative concentration of efforts?

I wouldn’t plan space around everyone working every day in the office, either. I would leverage telecommuting for the following purposes:
  • To maximize the available collaboration space.
  • To maximize personal productivity by allowing people to work at home when they need to concentrate on tasks that their teams need them to complete. 
  • To reduce the cost of office space required by a company.
Naturally, privacy areas would be available for people when they do come into the office, and I’m sure there will be those who feel that they need to come into an office every day to be productive (I’ve actually had people tell me this). In this new world where telecommuting is allowed, would everyone actually need their own office at work? I think not.

Communication and Collaboration: Essential Ingredients to Great Teamwork

June 5, 2009

In the face of global completion, businesses are embracing teamwork and collaboration with the goal of achieving greater collective performance than what can be obtained by focusing on individual performance alone. This begs the question:

What does great team communication and collaboration look like?

As a software development manager in an organization that has embraced self-directed, empowered teams, I have found that many people do not understand how team communication and collaboration differ from individual performance. In fact, people have blind spots that can impact team productivity. I’ll walk through some real-world examples to illustrate my points.

Watch the hand-offs
One area to keep your eye on as a manager is when work is being transitioned from one individual to another. As a software manager, I prefer to have the developer who will be performing the work be the person who estimates the work. I also resist taking people off of tasks that they have started because I believe that too much productivity is lost due to the ramp-up time required for people to get their heads into the task. But on occasion, work does need to move from one person to another.

I was at a team meeting where one developer indicated that he needed to hand off a priority issue to someone else, mostly because the other developer had some specific knowledge and skills that were required to resolve the problem. The developer who handed the work off immediately indicated that he was “looking for other work to do,” but did not take on any task that was on the board. (And should have, as this is supposed to be the norm with our process.)

The developer that he handed the problem off to spoke next, and she said: “I’m taking this problem on, I’ll need about a day to get up to speed on the issue, but once I do I should be able to resolve it fairly quickly.”

I’m supposed to be quiet at these meetings, but upon hearing that – with no response from the original developer who just said that he was looking for work – I couldn’t help but speak. “It sounds like,” I said, “that if Charlie sits with Brenda for a couple of hours, we should be able to cut down on the time Brenda will spend getting up to speed, helping to move this priority issue along.”

They agreed! It was simply a case of Charlie (real names have been changed) not considering that he could help Brenda along; he had reasoned that he had done all that he could and needed to give the problem to someone else, and basically washed his hands of it without even considering that he could – and should – help move things along through a little collaboration on his part.

A little coaching was required to point out that keeping the team moving is important, and that a hand-off is fine for simple tasks, but a transition is necessary for complex tasks.

Most of us are not working on quiz shows
Ever felt like someone is forcing you to ask question after question? There are some people who have had long experience with a command-and-control environment where they actually expect that it is someone else’s job to quiz the information out of them.

I had this experience with a project team was working over a weekend to meet a critical customer delivery. We were correcting a problem with a custom tool that extracted data from a database and processed that data – our problem was that we were retrieving some data that we should have been excluding. The development team worked through Friday making changes so that we could hit the ground running on Saturday with our testing.

About mid-morning on Saturday, I hadn’t heard how test results were coming along. Since almost everyone was working remotely, I sent a short e-mail message to the lead tester, asking: “How is the testing looking?”

The response came back: “Fine, it’s running a little slow, though.” Knowing that we had changed our selection criteria, I expected to take a small hit in performance. Of course, the limited information contained in the response led me to ask the person to qualify what he meant by “a little slow,” as well as where he was observing the problem.

To give you some additional background, the evening before this same individual tested our older version of the software on the same database and was able to process the information in twenty minutes. What was he seeing now?

He reported back to me that his test with our “fixed” software had already executed for two hours, and he estimated that it would be another two hours to completion! Obviously something was very wrong…

From a communication perspective, it would have been extraordinarily helpful if this person had taken the initiative to raise the performance flag after we passed the forty-minute mark without being asked (let alone what we were actually experiencing); if our software was taking twice as long to process without being complete, everyone would have known we had a major problem. If I hadn’t asked, I’m sure that I would have heard anything until mid-day – after the processing was complete – that we had a problem.

Barring that, this person knew that there was a problem when he gave me his initial response, and he could have provided essential details in his response. If I didn’t ask for specifics about what he was observing, the net result would have been the same as my not asking my first question. We would have found out half-way through the day that things were very wrong, after his test was complete.

In this particular case, the individual was used to teams that worked under very tight control, and he needed to understand that in the self-directed world that he was now a part of, you need to think about what information is important for others to know, and to communicate that information fully. For him, it was a matter of pointing this out and setting expectations going forward.

One related point: The act of responding in greater detail may trigger a proactive response on your part. As you supply information, you start thinking more deeply about the situation and even ask yourself key questions that will help keep things moving forward.

What was causing our performance problem? We had a server configuration issue. The decrease in performance was actually due to “processing” time being consumed by very detailed logging reserved for debugging scenarios.

I’m sure that if the tester had put more effort into responding in greater detail, it might have occurred to him to check the next logical option – the configuration file settings. Once we asked him to check for and make a simple configuration change, everything to be processed normally, within the expected time frames.

The team needs to win
There are times people optimize their individual performance without consideration for the team. Are your annual performance plans a cause of this?

If “collaboration” and “teamwork” are line items in contrast to specific, more detailed, individual goals and objectives, the individual will naturally optimize their work towards what carries importance on their performance evaluation. Other times it is simply a matter of work style and personal preferences that are getting in the way.

One example where a personal preference almost caused lost productivity involved a couple of my developers that were collaborating on a rather time-consuming, difficult problem. I was a part of a meeting one morning where we discussed how to attack the problem. Given the nature of the issue, we had a good idea of what code was involved, and we worked out what tests needed to be conducted in order to isolate the nature of the problem.

It was agreed that one of the developers would conduct tests and report the results so that the other, more experienced developer could then fix the code. Even though we had a good idea of where to fix the problem, the results of the testing would help us understand the exactly what needed to be changed. And while this was issue was a high-priority task, the experienced developer had other things that he needed to do, so it was agreed that he could work on his other tasks until the test results were in.

Around 2:00 pm that same day, the developer conducting the tests had his results. He was pleased that the tests confirmed what we had suspected, and told me “I’m going to write this up from my notes and get it to Bill.”

I recognized that this developer was very meticulous, and his own personal style was one of carefully documenting each step along the way – which was very useful if he needed to refer back to something because he always had a good record of what he worked on. However, there was someone else waiting on this information, and his personal style was going to prevent that person from learning about the tests for at least an additional hour or two – suboptimal from a team perspective.

I quickly interjected my thoughts; “Since Bill is waiting on these results, let’s get with him now so that you can give him a rundown on what you found. That way, he can start making changes before close of business today, and you can follow up with your written results once you have those complete. We can use those results to double-check the changes to ensure that we don’t miss anything.” The developer agreed that this was reasonable, and the issue was resolved within that same day.

Conclusion
Good team communication is all about what considering what it takes to keep the team moving. If teams are having problems performing, examine the areas where communication and collaboration are occurring to evaluate whether individuals are focused on the team or themselves, and if they are sharing complete information. It's all about flow.

And don’t fault people, but coach them about the differences of team communication and collaboration, and set the expectation that individual performance may take a back seat to team performance.