Please Update Your Software Engineering Curriculum!

… yes, prominent university with a Computer Science or Software Engineering-related program: I’m talking to you. It’s time to get with the times. If you claim to prepare Software Engineers/Programmers/Developers for a real-world career in software development then you NEED to understand what employers are looking for and you NEED to be teaching the following things:

  • Software Craftsmanship / Clean Code – The importance of writing clean code is completely overlooked by universities. A large project that is poorly coded will dramatically increase a company’s maintenance costs as well as the cost of adding new features. When I went to college (~10 years ago), nobody — not even once — looked at the code I was writing and told me how terrible it was. Rushing out sloppy code to solve a problem doesn’t cut it in a professional workplace. We need to teach students how to write good, clean code!
  • Agile Software Development Methodologies – This is now the standard for software development. In retrospect, reading about this in a book isn’t an effective way to learn about these topics. Students need to have an actual project where they build a software product over the course of one or more semesters using an iterative methodology.
  • Design Patterns – For me, reading about design patterns in a book before having real development experience was entirely ineffective. Students need to learn about design patterns and incorporate them into actual software projects for the lessons to sink in.
  • Source Control Systems – Absolutely every single developer will be using some form of source control as part of their professional job. Students need to learn about modern source control systems (like Git) and should develop good habits early on in their schooling.
  • Unit Testing and Test Driven Development (TDD) – This is a big one. Unit testing and especially TDD is a major mind-blower for most people and has a huge learning curve. The sooner students can incorporate unit testing into their normal development process the better. An employer that has to teach a graduate about unit testing from scratch is going to be discouraged from hiring that candidate… but I still haven’t seen a curriculum that includes unit testing. Any respectable employer is going to want developers who have a strong understanding of unit testing.
  • Modern Web Development (HTML, JavaScript/JQuery, CSS) – Every software developer ought to know at least the basics of web development. There should be multiple electives that let a student specialize in this area since there is such a high demand here. The courses should be updated frequently to keep up with modern trends.
  • Data Persistence / Databases – Almost every single developer is going to need to be familiar with databases and data persistence techniques. This needs to be part of the core curriculum — not just a single class or elective.
  • Mobile App Development  – This is another skill that is in extremely high demand. Students should at least have an elective or two available in this area so they can get exposure.
  • User Experience (UX) Design – Students should have an understanding of the importance of building a good user experience. Poorly designed user interfaces make software painful to use and turns customers away.

It’s apparent to me that universities (at least in my geographic area of interest) are really dropping the ball in most of these areas. Programs like Code Academy and coding bootcamps appear to be nailing it and are looking more attractive all the time. Let’s face it: if you can take 19 weeks of straight-up programming-related classes teaching the aforementioned topics, you’re already ahead of a traditional bachelors degree university student.

Keeping current with technology and methodology trends will require close collaboration with real, practicing Software Engineers and cannot rely on professors who fall out of touch with software development. This is going to be tough, but if universities don’t get with the program they are going to be left in the dust.

Have you found a program that teaches these concepts? Please share!

To Blog or to Code?

A couple of months ago my buddy and colleague Dave Shah initiated a book club to read Uncle Bob Martin‘s Clean Code. While it was Dave’s 3rd(ish) time reading the book it was actually the first time for me. Wow. With literally every chapter I found myself thinking “Geeze, I wish I knew all of this 10 years ago”. If you haven’t read the book then you really must. It is an absolutely essential read for any developer who cares about developing good software… but I digress.

Reading the book really caused me to reflect on the technical debt I had unwittingly inflicted over the years. It also made me realize that I’ve never really given software craftsmanship a real shot. That is, the best code I’ve ever written was woefully oblivious to things like the Law of Demeter, the Single Responsibility Principle, and even good naming conventions. My role as a Development Manager has ironically and gradually pulled me away from what should be one of my most important areas of expertise: software development.

So after feeling inspired and excited about a new (to me) way of thinking about programming, I decided to start a side project with the following goals in mind:

  • Try to deliberately practice Clean Code principles like TDD, refactoring, good naming conventions, the SOLID principles, Demeter’s Law, etc.
  • Finally learn how to use GIT and GitHub (check out!)
  • Try to get caught up on the current state of ASP.NET. This includes ASP.NET 4.5, MVC 5, Entity Framework 6 using Code First and Migrations, etc.
  • To check out the Windows Azure platform for hosting a website and database
  • To figure out how use Google Universal Analytics and the Measurement Protocol for pushing event data from the server-side
  • Figure out how to publish NuGet packages (check out this package I built to help with pushing Google Universal Analytics events via the Measurement Protocol

I’m excited to say I’ve mostly completed all of my goals — although the clean code part is a lifelong journey of course. However, to find time to do this I’ve deliberately squeezed out almost all of my personal free time. I can honestly say it has been extremely rewarding. Computer gaming has always been my favorite pastime, but I’ve always known it really doesn’t amount to much of anything other than short lived fun. While I may not be having quite as much fun in the moment while I program, it’s a more rewarding variety of fun.

I hope to blog on many of the things I’m learning and have learned but at the moment I’m really just having a great time coding!

I would be delighted if you’d check out my code on GitHub and tell me what you think. Feel free to skewer me — you won’t hurt my feelings! My only goal is to learn and get better.

Also, if you like to play board/card games with a fairly stable group of friends, maybe you’d like to check out my website. It’s totally free. I welcome your feedback!

Cycle Time and Thin Vertical Slices

Cycle time is an under-appreciated metric that can provide insight into the effectiveness of a development team. Velocity (aka throughput) is usually the metric that gets all of the attention. However, shifting some of the emphasis away from velocity and onto cycle time will probably increase your velocity anyway, and the customer will benefit as well.

What Is Cycle Time?

Cycle time represents the amount of time it takes for work to flow through a system. To oversimplify some otherwise very interesting math, Little’s Law basically states:

Cycle Time = (Average WIP) / Velocity

A high velocity with a low average work in process means you have a low cycle time. A low cycle time means that once a team begins work on a feature it will generally be completed fairly quickly. A high cycle time means the opposite.

How Do We Improve Cycle Time?

You can decrease your cycle time by increasing your velocity, by decreasing your work in process, or by breaking your work into smaller chunks (although this isn’t as obvious from the formula). Four separate 5-point stories will flow through the system faster than a single 20-point story. Since increasing your velocity is typically difficult to do, decreasing your work in process and breaking stories into smaller units is usually the most practical way of improving cycle time. Imposing limits on the number of stories or points that can be in development will help ensure that the emphasis is on pushing existing stories through the system rather than starting new ones.

Why Is Cycle Time So Important?

Imagine you had a project with 100 well-defined user stories. Would the customer rather have one story delivered per day for 100 days or would they rather have 100 stories all delivered on the 100th day?

In both of these cases the team’s average velocity over these 100 days is the same. However, in the first scenario the team with the low cycle time is able to show constant progress to the customer. A low cycle time also means it is easier for a high priority feature or bug fix to be delivered quickly.

Thin Vertical Slices and Cycle Time

I recently began working with two small development teams that are new to the concept of user stories and thin vertical slices. The teams were mostly used to doing development in the form of thick horizontal layers. In other words, they take a group of features and break the work into data access vs. business logic vs. UI development tasks. They completed all of the work in one layer then move on to the next. The result is usually a very high cycle time and lumpy delivery of features.  It is likely in this model that features will be completed in batches and the hand-off to Quality Assurance (QA) can be overwhelming.

But why should we care? Of course the customer would usually prefer to see progress at frequent intervals but what if the they really only wants to see the final product? Does cycle time matter then?

Yes! The importance of cycle time is intensified when there is a hand-off in your process. An example would be the development team handing off a feature to QA for testing. Another example is QA handing a feature off to the customer for user acceptance. If the development team is doing work in thick horizontal layers they are likely dropping huge bombs of features on QA in sporadic intervals. QA can be left with nothing to do for days or weeks and then suddenly they become the bottleneck. This is wasteful and will decrease the team’s velocity. It can also place unnecessary pressure on QA which can have a negative impact on quality. Likewise, reducing the team’s cycle time will reduce waste, improve quality, and ultimately increase the team’s velocity.


Cycle time is an important metric that can be used to improve a team’s velocity by reducing waste and improving quality. Strive to improve cycle time by enforcing lower work in process limits or breaking down work into thin vertical slices of functionality. Teams with low cycle times can show constant progress to their customers, are more capable of reacting to unplanned work, and perform better all around.

Does your team pay attention to cycle time?

Deliver Solutions, Not Code

While it might sound like a good idea, giving your customers what they ask for might be doing them a disservice.

Often times the customer will come to us with a solution already in mind (“We need a single screen where you can enter your order and do your checkout AND print your receipt!”). Ideally though, the customer would present a problem instead (“There are too many steps to our ordering process and it needs to be less cumbersome”). An experienced development team has probably solved similar problems before and will have ideas that the customer may not have even considered. Usually these solutions end up being better and may even be less work. The development team will also have a broader understanding of the capabilities that technology brings to the table.

Regardless of how the problem presents itself, solving the problem should be a collaborative effort. The development team should be able to propose multiple solutions from which the customer can choose and tweak. Even if your customer(s) always present problems in the form of premeditated solutions, it is a moral obligation of the development team to counter-propose better solutions if one exists. Nobody understands the problem better than the customer; therefore, the customer should ultimately be responsible for selecting (or at least accepting) the solution.

Admittedly, not all development teams are staffed for this model of collaboration. However, development teams should strive to collaborate with the customer to deliver solutions, not just code.

Prioritizing Technical User Stories

As with most software development teams, we struggled with the notion of “technical” user stories early in our Agile adoption. By technical user stories, I’m referring to stories that are difficult to express in the form of a business case that is easily understood by a non-technical person. Usually these stories provide some benefit that isn’t in the form of a new feature. Some types of technical user stories could include:

  • Refactoring code to reduce technical debt
  • Infrastructure or framework upgrades
  • Researching the latest technical hotness

Attempting to write a business case for these stories in the usual fashion often times ends up something like this:

As a Developer I can use the latest version of Java so that I can use it’s cool new features.

— OR —

As a Developer I can refactor the MngrHelperObjectUtil class that was created 9 years ago before we knew what we were doing so that I don’t have to be terrified for my life and take 3 months every time I need to make a change in that godforsaken code.

These business cases aren’t usually very compelling to the product owner as they are difficult to explain and are in direct competition with normal features. So how do these stories ever get worked in?

Not Everything Deserves An Independent User Story

First let me address the problem of stories around refactoring code. It has been my experience that this kind of work usually does not deserve an independent user story. The business case of “so that it’s easier to maintain in the future” is a tough sell unless “the future” means tomorrow.

If you’re already planning on making changes to the code in question then you have a stronger case for refactoring as the payoff will be more quickly realized. As an alternative to creating a new story for this refactoring work, try bundling it with another story that requires you to make changes to this code anyway.

When trying to determine how much refactoring to do, a good rule of thumb is that it should be proportional to the size of the change you are making in the first place. In other words, if you are making a small change then do a small amount of refactoring. This way, you don’t end up with low-value features costing too much; this won’t fly with the Product Owner.

What About Work That Does Deserve An Independent User Story?

As I mentioned already, we struggled with this early on. We tried to take care of these stories under the radar. We didn’t bother prioritizing them with the Product Owner and just understated our capacity so that we would have at least a little bit of time to work on these stories each iteration.

This is clearly the wrong approach for a number of reasons. Your Product Owner needs to be aware of these stories. Some iterations may require more capacity devoted to these stories, and other iterations may not require any technical stories at all. Not accounting for these stories would cause variations in your velocity that make it difficult to plan.

Another approach we tried was just carving out X points each iteration to be devoted to technical stories. This was similar to what we first tried, but at least this way the Product Owner was aware that it was happening and we had a better picture of our velocity. Once again, we found that this approach didn’t work well as the number of points needed for technical stories varies from iteration to iteration. For example, upgrading from Java 1.5 to Java 1.7 probably isn’t going to happen in just 5 points.

After many months of evolving our process we ultimately realized that we just needed these technical stories to be prioritized like any other story. This means that the Product Owner has to understand the benefit of these stories.The development team (or perhaps the Scrum Master) needs to champion these stories and sell them to the Product Owner. It has been my experience that any reasonable Product Owner has no trouble prioritizing these stories.

Going through the prioritization process also has the added benefit of keeping the development team honest. As developers, we have a tendency to want to upgrade to the latest and greatest — but sometimes we need to really think about why and justify taking the time to do it.


Where possible, include technical work as part of a related story rather than making an independent story. Refactor code when you are already modifying code in that part of the application. When technical work warrants its own story, make sure that you prioritize this work with the Product Owner just like any other story. You’ll have a better picture of your velocity and it will help ensure that you only take on work that actually needs to get done.

Communication Without Disruption: A Manager’s Quandary

In the early days of being a Development Manager, I used to make the rounds four to five times a day asking each member of each team: “How are things going? What can I do to help?”.  Sometimes I would get the opportunity to assist, but most of the time the response was something along the lines of “Everything is going well, no help needed”.

My intentions were good and were totally in line with my responsibilities. However, I think it was around the first time that I heard Scott Hanselman’s talk on productivity (see his blog post on the topic) that I really started to realize the cost of these interruptions. Even something as simple as a yes/no question (“Need help?”) can break somebody out of “The Zone”.

It is important that team members get uninterrupted time every day. Part of not interrupting someone is being able to tell when they actually are in The Zone. This isn’t usually rocket science; if you see that someone is really intensely focused, then don’t bug them. If you have trouble telling when someone is in The Zone then work out a signal like wearing headphones, setting something out on their desk, etc. as a visual cue.

Another disruptive but convenient communication technique — and one that I am guilty of overusing myself — is instant messaging. Although we may not realize it, sending someone a message can be almost as disruptive as walking up to them and asking a question. A little blinky window at the bottom of the screen can be enough to break someone’s concentration. A phone call is even worse.

Ok, so how can we communicate with team members without disrupting? That is, how can we communicate without having to worry about breaking people out of The Zone? The most obvious way is to approach someone when they are clearly not in The Zone. What if you don’t have the luxury of sitting right next to the team member? Try email.

Yep. Good old fashioned email. Email is a great way of issuing an asynchronous request that says “hey, when you get a minute I need to talk to you about XYZ”. There are three benefits to this approach. 1) Your team member will likely only be checking their email when they are at a good stopping point. 2) Giving some sort of context as to the topic can allow them to mentally prepare. 3) They can choose to reach out to you when convenient for them.  As Paul Graham’s blog post suggests, a manager’s schedule is more conducive to interruption, so this approach won’t cost you as much time overall.

It takes discipline and patience to avoid disrupting your team(s). I often times struggle with adhering to these ideas myself, but it’s a work in progress.

Still Not Agile? Take Baby Steps

It’s 2014 and you still aren’t Agile. You haven’t had the luxury of upper management taking the lead and you don’t see any signs of that changing. How do you get started with Agile?

If you have management support then bringing in an Agile coach is a really great way to kick things off. You’ll have an expert to guide you and answer all of your questions. You’ll also have someone constructively calling you out on your unproductive habits. However, if you don’t have this option then the second best approach is to gradually work it in from the bottom up.

If you haven’t already, make sure you read the Agile Manifesto and the Principles behind the Agile Manifesto. Spend some time reading up on the purpose of the various ceremonies in Agile Scrum. I recommend Scrum because it’s the most widely practiced flavor of Agile, and it’s fairly prescriptive.

Trying to introduce all of the practices immediately will likely be too overwhelming. Here are three things I recommend you try first as they will add standalone benefit to your process, even if you never adopt all of the recommended practices.

Document Your Work and Make It Visible

Think of everything you are currently working on and will be working on in the coming months. Break that work into reasonably small units, say less than five days of work per item, and document each item on an index card. Write down just enough information that you will know what you are referring to if you look at the card a month from now.  This can be a team or individual effort depending on your situation.

Next, draw three columns on a whiteboard (or something comparable) and label the columns “Backlog”, “In Progress”, and Completed”. Now divide up the index cards into these three self-explanatory categories and tack them on the board. Congratulations. You now have an “information radiator” that broadcasts your current and upcoming priorities. Anyone can walk by and see what you are working on, and what you having piling up.

This is a useful enough tool for keeping track of your own work that it doesn’t necessarily need to be seen by others. However, people will look at the board. If you are lucky, a customer or your manager  will look at the board and ask you a question or two. “What does card XYZ mean? I didn’t know you were working on that.” or “I thought you were working on ABC, is everything OK?” These are good conversations to be having as they can help ensure that you are working on the right thing. Communication is key!

The board is also a useful tool for prioritization. When someone swings by to ask you to work on something you can grab a card, stand up, and have a constructive conversation about which of the things in your “In Progress” column should get moved out. After all, you can only work on so many things at once.

Daily Stand-up Meetings

Having a daily stand-up meeting is a surprisingly effective way to kick off the day. It is also a step in the right direction when it comes to frequent communication! Try to include everyone who is a regular contributor to the project. At a minimum, this should include the other developers and QA. In a perfect situation this will also include the Product Owner or customer, as well as any other cross-functional members of the team (e.g. UX Analysts,  Operations, etc.) that might not be 100% dedicated to your project.

I won’t go into all of the merits of a stand-up meeting as there are plenty of great resources on the topic (see Wikipedia for example). While you should be communicating with your team members in near real-time, a stand-up meeting guarantees you are communicating at least once a day.  This can be especially beneficial for getting some face time with a Product Owner or your customer, who may not be as integrated with the team as you’d like.

Retrospective Meetings

One of the principles behind the Agile Manifesto is that the team should be continuously improving. It states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Having a regularly scheduled retrospective meeting provides team members with an opportunity to talk about what is working, and what isn’t. As with stand-up meetings, you shouldn’t necessarily wait until this time to bring ideas to the table, but it does provide a guaranteed time slot to ensure you are devoting at least some time to continuous improvement.

In your first few retrospectives you’ll likely be talking about how to make sure the stand-up is adding value, whether you want to add another column to your board (e.g. “In QA” or “Needs Acceptance”), how to better document your work, etc. Make sure that you have a plan for implementing  at least one or two ideas from each retrospective and reflect on whether your most recent changes were effective.

Before you know it you should be talking about how to take the next steps to becoming more Agile. Perhaps you’ll want to establish a true development iteration. Maybe you’ll want to start estimating your work for planning purposes. Maybe you’ll want to select an unofficial Scrum Master or Product Owner for the team. Whatever you do, keep improving!


Documenting your work on a whiteboard, holding daily stand-up meetings, and retrospecting on your development process are three easy ways to start getting Agile. If you can implement these then you’ll start prioritizing more effectively, communicating more frequently, and you’ll ensure there is a guaranteed mechanism for improvement.

Have more questions about getting started with Agile? I’ve been through the bottom up approach and would be happy to discuss your own unique challenges if you need help getting started. Good luck.

Software Developer – Not Just Another Rung in the Corporate Ladder

I often see Software Developers (aka Developers aka Software Engineers aka Programmers, etc.) concerned with the long term prospects of remaining “just” a Developer. Although they may have an aptitude for software development, they fear that unless they get promoted out of a development role then their career will grow stagnant. To make matters worse, companies may even “promote” good developers to other positions — like a Business Analyst or Project Manager — which may be regarded as higher up the food chain. I contend that being a Developer is a career path of its own, and any “promotion” out of that role is probably just be a lateral move into a different profession.

Having filled the role of Developer, Business/Systems Analyst, Project Manager, and Development Manager, I can say with confidence that a great Developer can often times contribute to a software project in a bigger way than these other roles. In an Agile environment, a Developer is empowered not only through doing the actual development, but by helping with requirements, providing estimates, bringing new ideas to the table, testing, etc. On the other hand, a Business Analyst, Project Manager, or Development Manager most likely cannot directly contribute to the actual software development — which is of course the most fundamental thing that has to happen for software to get built. My point is that a Developer ultimately makes the most important contribution in a software development project, and may even have the most challenging job.

A second point is that good Developers scale in value much more quickly and for a much longer duration than most other professions. That is, a Developer with two years of experience might be twice as valuable as they were in their first year. A Developer with five years of experience might even be five times as valuable as they were in their first year. You can probably think of your own experiences where one experienced Developer was an order of magnitude more productive than a junior Developer. Many professions hit a plateau relatively quickly and do not see this kind of growth in value. So long as your contribution to work is growing year after year then you should expect to see your income growing year after year. In these other kinds of professions where your value plateaus quickly, you could understand why one might want to get promoted out of their role. The point is that Developers are valuable, and exceptionally good developers are exceptionally valuable. If you are passionate about development then you could reasonably expect to stay within the software development profession and make a good living.

That being said, these other roles can be equally impactful and can be extremely rewarding as well. If you are passionate about something other than development, or you believe you can make a better contribution as a Business Analyst/Project Manager/Development Manager/Team Lead/etc. then go ahead make the career change (but notice I didn’t call it a promotion).

Does the career path of a Developer scale at your company?

What Does a Development Manager Do?

As a (software) Development Manager myself, I am always pondering exactly what it is that makes someone great at this role. While surely every company has their own take on the role (if they even have the role!), here are my thoughts about what makes a good Development Manager.

As with other members of the development team, the primary responsibility of a Development Manager is delivering software. Obviously this needs to be the right product, with the appropriate level of quality, delivered in an acceptable amount of time. Without directly gathering requirements, doing design work, developing, testing, etc., how does a Development Manager contribute to delivering great software?

Here are what I believe to be the most important responsibilities of a Development Manager that have a direct impact on a team’s ability to deliver effectively:

  1. Ensure your teams are following an effective development process. This should likely include a focus on communication both within and outside the development team(s), a continuous improvement model like frequent “retrospectives”, and some basic mechanism for measuring and communicating progress. This is in large part what being Agile is all about. A hugely important function of a Development Manager could also be drumming up support for Agile if there is a culture challenge within your company.
  2. Do the normal managery stuff. Make sure teams are appropriately staffed and equipped. Mentor the team leads. Train and grow team members. Make sure people are happy. Be accessible. Break down barriers for your teams. Keep your teams informed of what is going on in the business. Participate in the budgeting process. Share responsibility for failures and shield your teams from politics and drama.
  3. Keep upper management informed. Upper management should know what your teams are about. Let them know about your teams’ successes and opportunities on a regular basis. The only way you can grow your teams and get the resources you need is if the company understands and believes in what you are doing. This responsibility would ideally be shared with the Product Owner(s).
  4. Understand the business and advocate technology solutions. As with a Product Owner, I believe a good Development Manager needs to have command of the company’s strategy and major initiatives. This understanding coupled with a strong grasp of technology and your teams’ capabilities puts the Development Manager in an excellent position to advocate solutions which can be delivered by your teams. Of equal importance can be understanding what is not a good fit for your teams. For example, don’t commit to building an enterprise chat system when there are perfectly good packages that could be purchased instead.
  5. Help wherever it is needed. A Development Manager needs to have a strong technical background and needs to understand all of the roles of the cross functional team. I believe a good Development Manager should be able step up and provide hands on help when the team really needs it. This could be anything from doing actual development to manual system testing to requirements refinement and gathering, or anything else that might be blocking the team. If this is happening frequently then it is a sign of a bigger problem, but occasional help at this level is appropriate.

What do you think are the most important functions of an effective Development Manager?