As many of you know, this summer I have traveled to México to learn about culture, language, and engineering. As part of my study abroad/internship I was put on a programming team and assigned a project to develop a software tool. This tool was intended to communicate with standard car radios.

The three of us were given 8 five day weeks, 8 hours a day, to do absolutely everything. Learn the excel sheet format for the different radio models commands, design a program to retrieve that data, design a database to store the data, create a friendly user interface, design a program to turn the data into encoded messages of standardized format for the serial radio communication, etc etc ad nauseum.

Or supervisor said such a tool would require around five months to properly design. It took us seven weeks and we weren't that serious.

How long do you think such a project would take? Is five months absolutely outrageous? Why?

Also: has anyone else been to México?

A decent programmer can program quickly and efficiently, getting the job done well ahead of budgeted time.

A really good programmer programs slowly for job security.

But did you use tabs or spaces? You probably used oop too.

I have been to mexico.

You're both right. If you throw design out the window, you can get a lot accomplished in less time, which is an appealing approach if the code is not expected to be regularly updated or maintained. In fact, the upfront cost of properly designing a project with a tight deadline is foolhardy in this scenario, and moving those costs to potential refactor work in the future to get a deliverable out as soon as possible is one of the principles behind agile methodologies.

As a programmer, you program as fast as the deadline dictates. The quality of your work is what is impacted.

In my last project at work, about 70% of the effort went into handling error cases that we didn't expect would occur to customers, but to make a robust commercial product, had to be done.

Theres a big difference between writing software, and writing commercial software that you expect people to pay for.

I didn't think about it but the AGILE method was explicitly mentioned as a standard method. However, it was definitely expected that code be able to be reused later. I would say we attempted to make the code as readable as possible and had to make the design "abstract"

Provide a metric and perhaps we can even begin to answer your question. Otherwise, I'll just answer "Programmers can program at 12 goolak's per day."

In a more qualitative sense however, I think Roy and Lathanide have the gist of it. Programmers program fast when they have tighter deadlines, at the expense (sometimes) of quality. Also, the nature of the work has a huge effect on things. Lanthanide's 70% overhead figure is not unrealistic at all. Sometimes overhead tasks like testing and stuff can literally take up over 90% of the task time.

Did you follow any particular methodology? The agile development process itself is not a methodology, though there are agile methodologies (such as Scrum). If by "reused" you mean "copied/pasted/tweaked", then yes, basically anything you write can be considered as such, but that's not what developers usually mean by the word. "Abstract" is also quite vague, and pointless abstractions are just making the code messier.

Given your description, I find it hard to imagine the code is anything more than sloppily hacked together—which is perfectly fine given the constraints of the request—to get it all accomplished in seven weeks. Here are a few questions that would confirm or deny it:

• How many unit/integration tests did you write?
  
• What database did you decide on, and how did you design your data access layer?
  
• Did you put your parser in its own library?
  
• Do your methods/functions follow the Single Responsibility Principle?
  
• Do you have to update the parser logic if the excel document changes (e.g., adds/removes columns)?
  
• How does the program that encodes messages know the serial radio format? Is it hardcoded, or does it retrieve it from the database or config?
  
• Do you even have any configuration files? What can be configured?
  
• Why is the encoder a program and not a library? Do you have to pipe the results of your parser to your encoder?
  
• If you broke out any of your work into libraries, what does their API look like? Did you write any documentation?
  
• What architectural design did you use when you wrote your UI? Did you use a framework?
  
• If the format of the excel document and the way you need to encode messages changes completely, do you need to update your UI application?
  
• How modular is your application? Do you have an IoC container / use dependency injection?
  
• How much error handling do you have? What happens if the parsed file is malformed? What happens if the application cannot communicate with the database?
  

My guess is that many of these questions are going to have negative answers (such as "We have no tests and only tested it manually") because you simply weren't given the time to build something flexible and stable.

I'll also guess that some of your answers are more reasonable (such as "The encoding rules are government-regulated, and it would be a waste of time to engineer a configurable way to encode messages considering they will likely never change").

Post has been edited 2 time(s), last time on Jul 25 2016, 4:45 pm by Roy.

In my experience it's very difficult to scope a project well. It's hard to spend time on what's important and easy to burn time on things that don't matter much. The more people involved the more bureaucratic and lagged the process becomes. You guys probably finished quickly by keeping a small scope and keeping the working team tiny.

If more features, more testing, or more of whatever else is decidedly important then development time can skyrocket to the moon and back.

None the program is for in house use only, I didn't design the database, don't understand what you mean by parser.
I think? No. It's too confidential to store like that, hardcoded.
They are in libraries. Confidential. Documentation is being written this week.
All handled. The only thing we didn't handle was if the end user (an engineer) replaces system files with renamed junk files. We cut the line there.

The part that goes through the structure of the excel file and extracts the data it needs.

I just wrote a python script for work with file paths hard-coded in.

It's as Roy said: the quality of the work is what suffers.

TiKels, any software that would ever be used in a production environment would have adequate tests and documentation. Don't be surprised if your code is scrapped after a hand-off because it wasn't sufficiently tested or documented (good if code reads well, but still useless without the other expected components). Ideally you would also get your work code reviewed by at least one or two peers every time you wanted to push a change. "Production" doesn't mean public either, all in-house solutions would follow the same protocol. When I'm developing BWAPI I can move quickly and push whatever I want, but when I develop for Amazon, a day's work on a personal project could take a week in a professional environment, even though we use agile.