Lessons Learned About Software Development

  • 820 views
Uploaded on

This is the transcript of a lightning talk that I've given to a few of my clients.

This is the transcript of a lightning talk that I've given to a few of my clients.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
820
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. LESSONS LEARNED ABOUT SOFTWARE DEVELOPMENTHello, my name is Jeff Thalhammer. Ive been a software developer for a few years. I still havea lot to learn about my profession, but I would like to think I have acquired a few bits of wisdomover the years. So in the next five minutes, Im going to share with you the most importantlessons that I have learned about software development... Lesson 1: The best code is no code at all.The moment you begin writing code, you start creating bugs. Every line of code is a futureliability. So the less code you have, the less risk you take on. This may sound counter-intuitive,but good software development is all about avoiding writing code.Code-avoidance happens in a lot of ways. For example, you might be tasked with writing codeto add up the sales figures on the quarterly TPS reports. But if you do a bit of digging, youll findthat you can just get the total by calling Mary over in the accounting department. Bam! Problemsolved with no code.Open source and commercial products are another good way to avoid code. Despite what youmight like to think, you are not special. A lot of problems have already been solved by people alot smarter than you or I. And if their solutions dont seem to fit, then you really need to thinkhard and justify why your needs are so different.Software itself is actually full of code-avoidance mechanisms: subroutines, libraries, objectorientation, web services, virtualization, cloud computing. These all exist for the purpose of notwriting code. Use them.As developers, it is hard to resist the temptation to write code. Thats what we are here for afterall. But that isnt really your job. Your job is to help solve problems in the most effective andprudent way that you know how. Code is just *one* of the weapons in your problem-solvingarsenal. So think about that before you write your next line of code. Lesson 2: Code is for humans first, and computers second.Once youve concluded that you actually must write some code, you need to remember who youare writing it for. And no, you are not writing code for the computer.Like all languages, programming languages are just a way for us humans to communicate witheach other and ourselves. We typically think that code is the "solution". But its not. Code isactually how we express the *problem*. Once youve fully expressed the problem, then acomputer will dutifully execute the solution. But -- this is key -- the problem is ours, not thecomputers.Unfortunately, computers arent very smart. So we have to invent these awkward littlelanguages they can understand. But we get so caught up in those little languages that we letthem constrain our own ability to express ourselves clearly, often to the point that we dont evenunderstand it.So when you write code, remember that you are actually trying to express a real human problemin an artificial language. So the more your code resembles a human language, the more likely it
  • 2. is to be an accurate definition of the problem. And if the problem is defined well, then thecomputer will probably give you the right solution. Lesson 3: You Are Not As Smart As You Think You Are.In many professions, you can at least identify the entire body of knowledge that youll ever needin that career. But the software industry is constantly evolving. Most of the things you learnedfive years ago are no longer relevant, or may be down right incorrect. True, some changes arejust fads and some learning is inevitably wasted on dead-end ideas. But how will you knowwhich are which?The only way for a person or an organization to succeed in this business is to constantly keeplearning. More importantly, you must learn how to learn effectively. You must question your oldhabits, seek alternative perspectives, and acquire knew knowledge. And just as important, youmust act on that knowledge. Otherwise, it is just trivia.So the challenge is to cultivate an organization that promotes effective learning. The good newsis that learning opportunities are everywhere. Every line of code, every presentation, everymeeting is an opportunity. But first, you must instill people (or yourself) with traditions and valuesthat enable them to recognize and exploit those opportunities. Lesson 4: Software development is 80% social and 20% technical.Writing code is the easy part. Anyone can do it. There are millions of developers in China andIndia who are willing and able to write code for you. And when technical questions arise, most ofthe answers are freely available. Just ask Google. The really hard part is figuring out *what*code to write.Figuring out what to write requires asking a lot of questions: What is the real problem we aretrying to solve? Which parts of the problem are constant? Which parts are subject to change?How likely is it to change? Which are the critical features? Which features are fluff? What kindof resources to we have available? The answers to these questions require conversations withactual human beings.So the message here is that to succeed in this industry, your social skills need be just as good(or even better) than your technical skills. You need to be able to communicate with people andfind out what they really need, how they feel, what their history is, what their goals are, what theyare doing.When working on a team, we all have different roles to play -- we each have our own areas ofstrength -- and thats fine. But as a whole, the team must balance their technical and socialskills. The unfortunate thing is that most organizations dont (or cant) really operate as teams.Developers end up playing lots of roles, some of which they havent really mastered. So forthem to succeed as individuals in that kind of environment, developers also need to be mindful ofthe balance between their own social and technical skills.Final thoughts: Quality is not an act, it is a habit. --AristotleThanks for your time.