tag:blogger.com,1999:blog-9793351095692680832024-02-18T21:46:35.918-08:00Getting the most from Information TechnologyAn exploration on how business can get the most out of its information technology efforts.Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.comBlogger106125tag:blogger.com,1999:blog-979335109569268083.post-5083632772591725252015-06-07T19:04:00.000-07:002015-06-07T19:04:00.077-07:00Do programmers need a degree in Computer Science?Note: this post was originally published on InfoWorld.com.
A recent survey from StackOverflow states that 48 percent of developers never received a degree in Computer Science. But when you look at the requirements for software developer jobs (at least in the Chicago area), it seems that most positions list a degree in Computer Science as a preferred item, if not a requirement. Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-88405018782773621062015-05-31T17:00:00.000-07:002015-05-31T17:00:00.263-07:00When organizational debt slows software projects downNote: this post was originally published on InfoWorld.com.
Most companies, when embarking on a major software project, have a fairly good idea what they need to accomplish from a high level. In many cases, though, the business does not know the details surrounding the software project well enough to make it truly a success using meaningful measurements. If you make software for aScott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-89381072555561236852015-05-24T16:47:00.000-07:002015-05-24T16:47:00.147-07:00Outsourcing a software project? Pay time and materials.Note: this post was originally published on InfoWorld.com.
Companies that look to hire an outside firm to help them create or deploy new software often will look to pay for that project using a fixed price agreed upon at the outset. This is so they can reduce the perceived risk associated with the project. This is usually the wrong thing to do, though, if you care about creating the Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-48502385300483829002015-05-17T18:34:00.000-07:002015-05-17T18:34:00.471-07:00Does software craftsmanship make project success harder to attain?Note: this post was originally published on InfoWorld.com.
There's a relatively new movement among software developers called software craftsmanship that focuses on improving the practices of software developers. On the surface, it seems like a good movement. After all, given the visible failures of software (the Affordable Care Act website failure and the Toyota accelerator Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com2tag:blogger.com,1999:blog-979335109569268083.post-55212705957483450402015-05-10T16:33:00.000-07:002015-05-10T16:33:00.481-07:00How just about everyone gets unit testing wrongNote: this post was originally published on InfoWorld.com.
One of the biggest ways that people could leverage technologies more effectively is to use unit testing correctly. Most teams either don't utilize unit testing at all or use it far too much -- it's tough to find that "sweet spot" where the tests increase quality without hindering productivity. But if you're able to achieve Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-80163539224976268462015-05-03T16:26:00.000-07:002015-05-03T16:26:00.935-07:00Making a business case for refactoring codeNote: this post was originally published on InfoWorld.com.
One common experience many companies have in the course of supporting software products is that the time and effort required to make customizations vary as the product ages. At first, customizations are easy because new features either mesh nicely with the existing code structure or they are completely new and can be easily Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-37047504601487216692015-04-26T16:22:00.000-07:002015-04-26T16:22:00.680-07:00Why time and budget are stupid measurements of project successNote: this post was originally published on InfoWorld.com.
Traditionally, software project success is measured primarily by two metrics:
Did we complete the project on time?
Did we complete the project within the budget?
If you think about it, though, these are somewhat useless success measurements. To illustrate why, I’d like to tell you about two projects that I completed while IScott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-44900700542860994882015-03-01T17:52:00.000-08:002015-03-01T17:52:00.552-08:00Beyond requirements: understanding what the business needsNote: this post was originally published on InfoWorld.com.
In my last blog post, I talked about how in some ways, the quality of software requirements can mean more to a project’s success than the skill of the programmers themselves. I also talked about how merely utilizing business analysts may actually make the problem worse. But what can we do about it?
Programmers need to know the product Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-58908952497416474302015-02-22T17:45:00.000-08:002015-02-22T17:45:00.507-08:00Low software quality? Poor requirements may be to blameNote: this post was originally published on InfoWorld.com.
When I read articles about improving the quality of software, I read a lot about new programming techniques and languages, as well as new ways to manage projects and requirements. But there have been times in my career when I was asked, as a developer, to work on a project that was destined for failure before I had written a line of Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-83301199960670509122015-02-01T20:47:00.000-08:002015-02-01T20:47:14.713-08:00On hiatusI have a new blog with InfoWorld! My contract with them allows me to re-post my entries here too, so I will not be abandoning this blog, but I do have to wait 15 days before I'm able to do so. That means that there will be a few weeks before I'm able to start posting here again. I plan to start posting here again before the month is over, but if you don't want to wait that long, you can check outScott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-59750121250199387702015-01-18T18:43:00.001-08:002015-01-18T18:43:35.846-08:004 common mistakes in rolling out purchased business software
If your job is to make software, and you're not living under a rock, you've probably heard dozens of stories of software projects that never made it to market because of uncontrolled scope creep, poor software quality, blown budgets, and the list goes on. In theory, purchased software should be safer, but I've witnessed more failures of rolling out purchased software than I have of custom Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-47979722324806782942015-01-11T17:41:00.000-08:002015-01-11T17:41:19.085-08:00Unclear specs? Maybe you need to stop writing specs.I read a blog post recently from a company describing how their product can help developers be more productive. I thought it was fairly interesting in that it talked about creating better specs and creating prototypes to help everyone understand the problem being solved. But it suffered from one fundamental flaw:
In the most successful software projects that I've ever worked on, we Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-14433351796314701252015-01-04T17:16:00.000-08:002015-01-04T17:16:54.547-08:00Creating a leadership team to make your software project a successIn this, my last post in my Leadership vs. Management series (a week later than I intended due to the holidays), it's time to put it all together and talk about what leadership and management are needed for the successful completion of a project. This is going to be a difficult topic to tackle in a single blog post since the leadership team you'd put in place for a 200-hour project in a small Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-8051756635352944052014-12-14T18:55:00.000-08:002014-12-14T18:55:44.845-08:00Creating a technology-centered culture
This is the last in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I have talked about four different levels (or stages) at which IT can interact with the rest of the business:
Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
Stage 2: Externally Neutral (Parity Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-31548905254588821772014-12-07T17:22:00.000-08:002015-01-04T18:31:22.685-08:00Cultural Roadblocks to Implementing AgileIf you had asked me a couple of years ago what type of people didn't like Agile software methodologies, I would have said "people who never tried it and managers with too much focus on the wrong success metrics". If you had told me that there were people who didn't like Agile because they didn't truly understand it, but tried (and failed) to deliver software using Waterfall methodologies altered Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-23761021526124034402014-11-30T17:17:00.000-08:002015-01-04T18:42:30.330-08:00Peter Principle and Software ArchitectsIt's time to address an uncomfortable truth within IT: technology professionals have a tough time finding, retaining, and promoting people with leadership ability. Instead, technology professionals, especially in consulting, tend to promote people based on their ability to do their current jobs and their knowledge of technology. This type of promotion leads to the Peter Principle, which is the Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-86258505298994025282014-11-16T17:20:00.000-08:002014-11-16T17:34:40.414-08:00Programming beyond writing code (Part 1)I recently came across an article by Laura Klein titled "Your Job Is Not to Write Code". I read the article because I happen to agree - it's a software developer's job to solve problems, and too many developers focus too much on the code and not on the problem at hand. I was hoping for another point of view, or at least something I could share on Twitter. Instead, I read a condescending and Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-6460666333902480232014-11-09T17:26:00.000-08:002014-11-09T17:26:02.259-08:00Hiring in service-oriented vs. innovative environments
This is the seventh in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I have talked about four different levels (or stages) at which IT can interact with the rest of the business:
Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
Stage 2: Externally Neutral (Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-29206712301067235972014-11-02T17:22:00.000-08:002014-11-02T17:22:33.619-08:00Wanting to move to Agile? Certifications are useless.A couple of days ago, I read an interesting article about how Agile certificates are actively destructive to the Agile community. One of the most important points he made was this: because Agile certifications aren't sufficient to prove whether you are an expert or not, companies that hire certified "experts" to launch their Agile efforts will fail, and therefore believe that Agile is not a validScott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com31tag:blogger.com,1999:blog-979335109569268083.post-68296289749932443142014-10-26T19:30:00.000-07:002014-10-26T19:30:48.585-07:00Getting programmers to see the value in managementIn my latest post in my Leadership vs. Management series, I'm going to discuss how to get programmers to see the value of management. Most programmers I know don't manage people very well and don't hold high regard for the managers they work with. It can be a fixable problem, though, if you understand the causes.
What is management, really?
Many people confuse leadership with management. To Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-27030009053149987372014-10-19T17:52:00.000-07:002014-10-19T17:52:50.770-07:00Why Agile Can't Work Without a Focus on User Experience
If you make software for a living, or work with people who do, you've probably heard of Agile programming techniques. Unfortunately what is not as common knowledge is user experience design. But it is extremely tough to do Agile programming well without also being able to incorporate user experience research into your designs.
What is user experience design?
User experience design, or UX Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-43454491191857187392014-10-12T18:24:00.001-07:002015-01-04T18:45:09.654-08:00Managing for consistency vs. managing for innovation
This is the sixth in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I have talked about four different levels (or stages) at which IT can interact with the rest of the business:
Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
Stage 2: Externally Neutral (ParityScott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-86374663067428506952014-09-28T17:14:00.000-07:002014-09-28T17:14:08.962-07:00How to Add People to a Late Project Without Making it LaterMany of my readers should be familiar with Brooks' Law, as quoted in Fred Brooks' Mythical Man Month:
Adding manpower to a late software project makes it later
The thinking for this statement is primarily that, when faced with tight deadlines, a software development team would spend more time getting new team members up to speed than they would just doing the work themselves. And so, people haveScott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-52198162708769282062014-09-21T17:32:00.000-07:002014-09-21T17:32:28.590-07:00How to leverage a Project Administrator effectivelyIn my second post in my series about Leadership vs. Management relating to IT, I talked about how project managers need to anticipate problems, decide which issues are worth fixing, and remove obstacles for their teams. Most IT people have worked for a "project manager" who merely ran reports, scheduled meetings, and constantly asked people for their status. In that article, I talked about how Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0tag:blogger.com,1999:blog-979335109569268083.post-27479492237837978062014-09-14T18:02:00.000-07:002014-09-14T18:02:02.260-07:00I'm not impressed by your Klout score. Here's why.As I've been getting more active on social media, I've started digging into Klout to see if I should care. (If you are new to Klout, I suggest you go to the Klout site to get an overview of what their score is.) Recently, I ran across this article that described one person's inability to get hired because of his Klout score, and his subsequent efforts to raise it which led to job offers and Scott Norberghttp://www.blogger.com/profile/08003954227206105408noreply@blogger.com0