Entries Tagged 'Software Development' ↓

When I was in college I was a professional comic book writer. After numerous submissions I had several stories accepted by three independent comic book companies, all slated for publication.

I even received a $100 advance for one of the stories, with all of them paying royalties on the “back end,” meaning I’d probably wind up making $100 per story if I was lucky. And back then $100 was a lot of…no, let’s face it, even back then $100 was nothing. But I could call myself a professional comic book writer.

On Being a Professional
Which is a joke, of course, because I wasn’t a professional. I was writing in a tiny bedroom, typically from 10 at night until 2 in the morning, cranking out a short script every week or two. Sure, I had honed my skills as a writer enough to match the myriad of others trying to make it, but I was not a professional writer. And I’ve had a hard time puting my finger on what it was that distinguished me from those whom I considered “legitimate” comic book writers. It wasn’t the fact that I worked out of a small apartment. Or that I wrote at night.

It was the fact that I didn’t consistently deliver under the pressure of deadlines.

I’m sure I’ll receive a few comments saying that a professional is someone who gets paid for what they do, or someone who does something as their main source of income, or someone who’s easy to work with, or someone who comments their code. Those are some of the components of being a professional, but one of the most important and often overlooked pieces of being a professional is consistently delivering a usable product in the face of deadlines.

How Many Deadlines Must a Man Walk Down…
I knew at least two guys who were amazing comic book artists. Both drew as well as the books on the shelves, but neither could draw an entire 22-page comic in a month…and that’s what it takes to be a professional in that game.

I’m not saying if you miss a deadline you’re suddenly an amateur – the continuum is much less binary than it is fuzzy. But during your career, your present job, or the past 6 months, how many deadlines have you hit? How many have you missed?

There are going to be extenuating circumstances. There are going to be times when a third party vendor flops and the project falls apart at the last minute. And there are going to be times when the deadline is set externally and you know from the outset you’ll never hit it. But if you find that there’s always a reason you aren’t hitting deadlines you have to start asking yourself: Is it you?

I know that somewhere between 55 and 90 percent of software projects fail. Missing deadlines is easy; I could get my mom, who knows nothing about software development, to come in and miss project deadlines. Does the fact that she showed up and collected a check make her a professional developer? She’s easy to work with and comments her code.

So here is my question: during your career, your present job, or the past 6 months, how many deadlines have you hit and how many have you missed?

This isn’t a show of hands, just a gut check.

An SbR reader contacted me looking for guidance on how to work with a group of un-motivated developers; his email is below (posted with permission).

I will post my reply next Monday, after giving you a chance to weigh in on the situation.

Q: “In the course of providing Change Management consulting services to an owner operated company, I got involved in trying to find out what was happening in their IT department (4 Software Engineers). They are all on salary with full benefits.

The IT Departments absolute priority is to insure the company’s current software and network system is operational. In general the current company system only requires minimal daily maintenance with periodic planned upgrades. Accordingly the Software Developers are able to focus the majority of their time on development of a new ERP software system.

They have been at the project for approximately 5 years. Design is complete and development is underway. After much discussion and prodding I managed to get them to produce a timeline to deployment versus completion. Deployment defined as being able to switch from using the current system to the new system with a minimum of equal functionality to the current system. The timeline is to a specific date versus effort in months. They arrived at the deployment via sophisticated process versus an educated guess so I believe it is realistic.

In my view stakeholders must have a deployment date and developers need a realistic deadline. We have our deployment date (set by the developers, not stakeholders) but I suspect they are not committed to it. They start at 8:00 am on the dot and are out the door at 5:00 pm. Lunch and coffee breaks are never missed. My concern is that they have been spoiled by not previously having a definitive deployment date so it is expected to balk at accountability.

My instinct is to shut the project down but I also do not like to give up.

[I'm looking for] direction on how to motivate this group to want to take ownership and to rise to the challenge of meeting the deployment date.”

If you were in his shoes, how would you handle this situation?

A Software by Rob reader writes:

I want to learn to program computers:

• What is your advice on becoming a good programmer?
• How do you acquire the knowledge?
• Is it necessary to know mathematics, specifically algebra, to be a good programmer?

I receive several emails per month along these lines, so I’ve decided to share my advice on the subject. Note that I said “my advice” and not “the one and only way”; there are too many paths for one person to know them all. Here are some thoughts based on my experience:

Q: What is your advice on becoming a good programmer?

Everyone I’ve talked to has taken a different path. Programming is different from other engineering disciplines; if you want to become an electrical engineer you go to school, graduate, work for an engineering firm, and one day take a test and get licensed. Programming is different because people do it as a hobby; no one designs electrical subsystems for fun. This creates more possibilities for learning how to code.

Here are the elements I think are key:

• Learn, learn, learn. You must have an insatiable appetite for knowledge. This usually means reading a programming book every few weeks in the early days, and moving on to more conceptual books like The Pragmatic Programmer, Code Complete, and Facts and Fallacies after 6-12 months of full-time coding. I can’t stress enough the value of reading, nor the value of immersing yourself in code early in the process.
• Transition into Concepts. Learning how to be a good programmer begins with learning logic concepts and language syntax; they are much easier to understand when taken together. But good developers quickly desire knowledge that transcends language syntax. Perl, PHP, Java, ColdFusion, ASP…all languages I used in my first 18 months as a professional programmer. What made me a good programmer was not my knowledge of each language, but my desire to understand and refine concepts like D.R.Y., the broken window theory, and code re-use.
• Hang Out With Programmers Who Are Better Than You. As a guitar player, the most I ever learned about the craft of songwriting was when I was hanging out with people who were much better than I. The same goes for writing software. And due to this new-fangled internet thingy you don’t even have to be physically present to be a part of the community: read programming blogs from the heavy hitters (Scott Guthrie, Rocky Lhotka, Dino Esposito, Scott Mitchell, etc…), check out programming forums, and look at other peoples’ code. Reading source code can be a pain, but the more you see the more you will be able to identity code that’s easy to understand, and code that takes a PhD to figure out how they output “Hello World” to the screen.

Q: How do you acquire the necessary knowledge?

There are a number of possibilities:

• A Software Apprenticeship. If you haven’t ready my article on Software Apprenticeships, I recommend you do. The best (and I would argue the quickest) way to become a good programmer is to write code under the wing of an experienced developer who will teach you not only the basics, but the in-depth knowledge that takes years of experience to learn. I consider this option leaps and bounds above all others.
• Learning while Doing. Want to learn to code? Get a job writing code. I don’t care if you make $5 an hour; you will progress more in 1 month as a full-time developer than you will in a year of hobby programming. There’s no better way to learn to program than to write code.
• Books & Mags. Books and magazines have been key in my quest for programming knowledge. When I’ve apprenticed developers in the past, I use books as their primary source of basic knowledge, having them read 1-2 programming books per month, while teaching them more advanced techniques in person.
• College. Having gone this route myself I am well aware of the limitations of the U.S. College system in preparing students for a career in computer programming. Preparing them for a career in determining little-o and big-O notation, sure, but actually writing code from the get go? Nope. College is great for high-level theory, but work experience trounces it when it comes to learning software development. Programming degrees from online schools are affordable, but nothing beats real-world experience.
• Tech school. I’ve only worked with one programmer who went to a technical school and she had good knowledge of language and coding concepts, but not a ton of theory or design knowledge. As a result, her code was utilitarian and used a lot of brute-force, but was often not well-designed or easily maintainable. There’s obviously a balance between not enough practical knowledge (college) and not enough theoretical knowledge (tech school). I am using a very narrow sample, so don’t take this as a blanket judgment of tech schools. Perhaps an SbR reader with more experience in this area can enlighten us. As an aside, the network administrators I’ve worked with from tech school have been well-trained and great to work with. Perhaps the nuts and bolts of networking are better suited for such a practical teaching approach.

Q: Is it necessary to know mathematics, specifically algebra, to be a good programmer?

Quite simply, no; it’s not necessary to know math in order to be a programmer.

If you’re developing games, then mathematics and physics play a large part, but building an invoicing application does not require much beyond basic addition and subtraction.

However, from personal experience, people who have an easy time learning mathematics and enjoy solving logic problems (be they algebra or how to move Mount Fuji), tend to learn code quicker and enjoy it more in the long run. It takes a twisted mind, my friends.

==

If you are interested in reading more on the subject of becoming a programmer, I’ve written a totally free 33-page ebook titled How to Become a Programmer: Everything (Non-technical) You Need to Know. You can download it here.

Mike Taber takes a good look at the questions I posed in my post The Next Frontier in Offshoring. I especially liked this comment:

“I lived in Rochester, NY for a very long time and quickly became what I would call a big fish in a little pond. I was great at what I did, but finding a new job that I was interested in was next to impossible.”

My wife and I have talked several time about moving out of a major city and into a smaller one, but I have a hard time believing I would be able to find the type of work I need to keep me excited, especially since I’m no longer satisifed to be a corporate programmer in a dark cubicle. How much room is there for a young technology hotshot in a town of 50,000 (the population of Hattiesburg)?

For some people the small city set-up is great. People who want a nice family-oriented lifestyle, low cost of living, and don’t necessarily get a ton of enjoyment or anxiety out of their work, could be forever happy with a small city/town lifestyle. I have a number of friends who fit this description, and I could see them moving to a place like Hattiesburg or Rochester. Honestly, I often wish I were one of those people.

And then there are those who have what I call a “divine restlessness.” It’s the blessing and curse that makes certain people have to strive for achievement and be constantly learning to stay interested, entertained, and happy in work work and in life. I am definitely afflicted with the latter, and thus smaller-city life is probably not for me.

When it comes down to it, small city life vs. big city life is a matter of taste. And the key to staying happy with your career is to know your own taste beyond the shadow of a doubt.

I have a friend who works for BearingPoint (formerly KPMG Consulting), and she wrote to tell me about her firm’s newest Global Development Center (which are basically off-shore, low cost software development offices). They currently have centers in India and China, and their next destination is…Mississippi. That’s right, a Global Development Center in Hattiesburg, Mississippi.

It turns out Mississippi has a low cost of living (thus low wages) and satisfies the need for clients like the federal government that require work be done in the U.S.

From a financial perspective (though some might call it greed) this seems like a logical trend for some businesses to follow, and similar to one call centers travelled in the 1980s before the internet made “around the world” into “down the block.” But as a fellow developer I’m curious to hear your thoughts on the following questions:

1. Is it a good thing that development work is moving to low-cost areas, but staying within the U.S.?
2. Is this a savvy business move made to keep a company competitive, or a devious, greedy move made to take advantage of developers and pocket fistfuls of cash?
3. Would you be interested in moving to a low cost area of the U.S. (read: the middle of nowhere) and working for less money, but having a better quality of life with no traffic and cheap housing?

After publishing Nine Things Developers Want More Than Money late last year, I received several requests for something that could provide more specific information than the 1-9 score on Rob’s Criteria for Keeping Your Developers Happy. In other words, managers want to know which of the nine areas to focus on, and most who wrote suggested I create a survey they could give anonymously to their developers.

In response, I’ve created a 29-question survey that covers all nine of Rob’s Criteria. I built it in HTML so you can print it out and distribute paper copies, or write code to place the responses in a database for easier analysis. If you wind up using a database I’d appreciate if you would send me a copy of your code so I can post it here.

The survey does not have a norm since it has not been administered to anyone. As a result, determining the results will be up to your interpretation. Hopefully that’s not too difficult given the nature of the questions.

If you have other questions you’d like included, or stories to share about survey results, please post them in the comments.

While building a report a few weeks ago I realized something I’d never thought of before: in user interface design, the more flexibility something offers, the more complex it tends to become.

This is an obvious conclusion, but I had never thought of it in these terms before.

A Simple Report
A few weeks ago I built a report. The first iteration used a hard-coded SQL query called by a page with no visible input parameters. The UI was delightfully simple: a single button marked “Run Me.”

The next step in designing something usable was to add two input fields for the start and end dates. At that stage I had a report that was fairly simple, but not very flexible.

Next, I added three parameters that allow a user to narrow the report by Customer, State, and City. With that the report became slightly more flexible, but also more complex. Luckily, this is where the complexity ended (read: the need for flexibility ended). It’s a good thing, too, because the interface was beginning to look busy.

If I had continued along this path to absurdity, I could arrive at a single text area for inputting SQL queries. This approach would be extremely flexible, but far too complex for business users.

Shopping Carts
Another example of this inverse relationship between simplicity and flexibility can be illustrated with online shopping carts.

Someone asks me every month or two about online shopping carts, typically: “If I want to sell a product online, which shopping cart do you recommend?” My first question is always: how technical is the person who’s going to manage it? (read: how much complexity can they tolerate?)

The simplest option is something like Yahoo! Stores or Shopify. Simple, yet configurable to the extent Yahoo! or Shopify allow in their control panel.

A more flexible approach is purchasing an off the shelf shopping cart that can be customized by a programmer. Products like .netCART contain loads of functionality, but they’re geared towards technical people rather than business owners, since they are too complex for the average person to configure. They offer loads of flexibility with lots of complexity.

And finally, the most flexible shopping cart one coded from scratch. Super flexible, very complex.

Cake and Eat it, too
With an entire design movement built around simplicity, it seems warranted to ask: can a design be simple and flexible at the same time?

In thinking about this, Gmail comes to mind since it’s simple enough for my mom to use, but flexible enough to serve the needs of more advanced users (and once they get POP3 retrieval out of beta it will be that much more powerful). Google achieves this by making common tasks obvious, and uncommon tasks hidden. Want to send an email? It’s right in front of you. Set up POP access? It’s in the settings menu. The more advanced items are hidden from beginning users, but the key is that they can accomplish 99% of their tasks without every looking in Settings. In fact, that’s one way Gmail succeeds where Outlook fails.

I also find the WordPress blogging engine flexible and powerful, yet surprisingly simple. As with Gmail, the WordPress team has managed to create a product with a ton of features that somehow leads beginning users to where they need to go quickly and effectively. I’ve introduced several newbie bloggers to WordPress, and never once have I had to answer basic questions you’d expect (“How do I create a new post?”, “How do I change the skin?”). Yet WordPress is insanely configurable through the administration console, its configuration files, skins, and add-in modules.

These applications do a good job of making common tasks trivial, while shielding the user from advanced tasks until they have the need or motivation to seek them out. These applications are not simple, nor are they feature-limited, but they do an amazing job of catering to beginning and advanced users at the same time.

The Holy Grail of UI Design
In doing so these applications provide flexibility and simplicity simultaneously; a feat that’s difficult and often expensive to accomplish because it fights the natural tendency towards complexity. Ultimately, I believe this combination is the holy grail of UI design.

A few months ago I wrote an article for Work.com titled Choosing a Company to Build Your Software. Work.com is geared towards non-technical small business owners, so the article is less technical than my typical fare, but soon after I published it I received a request from the folks at Work.com for an article on the ins and outs of open source software from a small business owner’s perspective (Should they use it? What applications are best? What are the pros and cons?)

I haven’t had time to write it, so consider this an open call to any SbR reader who wants to show off their knowledge of open source software. Gain credibility! Win Friends! Influence people! Visit Work.com for more details on writing a guide.

If you drop me a line once it’s complete I’ll link to it.

Dear Software Managers of the World:

We, the Software Developers of the World, realize that our two factions have had many disagreements over the years. Through this letter we would like to extend our hand in a gesture of reconciliation.

This letter contains two lists: the first list describes responsibilities we are willing to accept wholeheartedly, assuming you are willing to accept the second list with an equal amount of zeal and commitment. These lists are not intended as indictments of either side, rather glimpses of an ideal world where developers and managers work together in harmony.

We, the Software Developers of the World, agree to the following:

1. We will do what it takes to get the job done without being asked, including working extra hours (as long as it does not violate clause 1 in the section below).
2. We will not complain when we are assigned boring tasks, bad problems, or have to maintain someone else’s code (as long as it does not violate clauses 4 or 5 in the section below).
3. We will bring issues to your attention constructively and with proposed solutions.
4. We will seek to understand a decision before questioning it.
5. We will build the best software we are able to.
6. We will be loyal to the company and our team.
7. We will be passionate about the software we build.
8. We will be available when you really need us.
9. We will fully document our code and designs.
10. We will happily coach and mentor new developers.
11. We will tell our friends how cool it is to work at our company.

In turn we ask that you, the Software Managers of the World, agree to the following:

1. You understand that “crunch time” is an unexpected part of software development. Unless we have substantial equity in the company, crunch time will not exceed 3 weeks during any 6 month period.
2. You will give us powerful, best-of-breed PCs, huge hard drives, large monitors, and the latest development software.
3. You will listen and take action when we constructively bring a problem to your attention.
4. You will ensure that at least 80% of our time is spent on good problems.
5. If you plan to call us when software breaks, we will be given time to refactor and stabilize it as needed.
6. You will not ask us to serve as technical guides for highly paid contractors only to be held responsible when their code single-handedly brings our operations to a grinding halt.
7. If marketing is allowed to set our deadlines based on their knowledge of software projects, we will be allowed to set their budget and/or revenue expectations based on our knowledge of marketing.
8. You will not ask us to compromise a solid, stable, and maintainable design in order to meet an unrealistic deadline.
9. You will communicate expectations to to the stakeholders. You will ensure that before we begin building an application, all stakeholders spend ample time reviewing and understanding the specification.
10. You will ensure that as new requirements arise we will be given the corresponding amount of additional development time.
11. You will pay attention to your people more than your bottom line.
12. You will make our company a cool company to work at so we’re not lying to our friends.

We hope you take these items under consideration and we look forward to how these changes will positively affect our relationship as we continue to work together to build software for many years to come.

Sincerely,

The Software Developers of the World

Digg this

If you liked this post you’ll also like Nine Things Developers Want More Than Money.

Thanks to Mike Taber, Andrew Black, Jeremy Lukensmeyer, Dave Standring, and Adnan Masood for their input. Special thanks to Mike Taber and Dave Standring for reading drafts of this post.