Wastholm.com

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master:

"How long will it take to design this system if I assign five programmers to it?"

"It will take one year," said the master promptly.

"But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?"

The master programmer frowned. "In that case, it will take two years."

"And what if I assign a hundred programmers to it?"

The master programmer shrugged. "Then the design will never be completed," he said.

Someone who knows how to search for code examples and how to learn from the work of others will be more or less self-sufficient. They can learn and grow their skills on their own without needing someone else to do it for them. The ability to learn and grow your knowledge is the single most important skill for any developer. Without the ability to grow you will find yourself quickly deprecated. I do expect people to know how to use the language and/or framework they were hired to work in, but I judge them primarily based on the work they submit. A guy who can figure out how to do things that he doesn’t know how to do, on his own, on the fly, is a real programmer.

Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.

Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.

Software obeys the laws of entropy, like everything else. Continuous change leads to software rot, which erodes the conceptual integrity of the original design. Software rot is unavoidable, but programmers who fail to take conceptual integrity into consideration create software that rots so so fast that it becomes worthless before it is even completed. Entropic failure of conceptual integrity is probably the most common reason for software project failure. (The second most common reason is delivering something other than what the customer wanted.) Software rot slows down progress exponentially, so many projects face exploding timelines and budgets before they are killed.

Manage your projects with Wedoist and improve your productivity and collaboration.

Open-source project management tool, intended to assist the collaborative aspect of work carried out by agile software development teams.

* Free / Open-source (MIT License) * Full Development Life-cycle * Comprehensive Adminstration * Multiple projects within one instance * Powerful Add-on Interface * REST-API (Example) & RSS Support (Example)

A collaborative web-based system for projects and project management; WebCollab is easy to use, and encourages users to work together. The software is functionally elegant and secure without being cumbersome for users, or graphically intensive.

The software is ideally suited to tracking multiple projects and innumerable small tasks across an organisation of any size. If you have reminder notes stuck all over your desk, then you need WebCollab!

Software maintenance is not like hardware maintenance, which is the return of the item to its original state. Software maintenance involves moving an item away from its original state. It encompasses all activities associated with the process of changing software. That includes everything associated with "bug fixes," functional and performance enhancements, providing backward compatibility, updating its algorithm, covering up hardware errors, creating user-interface access methods, and other cosmetic changes.

In software, adding a six-lane automobile expressway to a railroad bridge is considered maintenance—and it would be particularly valuable if you could do it without stopping the train traffic.

Is it possible to design software so it can be maintained in this way? Yes, it is. So, why don't we?

We began this analysis of corporate life by exploring a

theoretical construct (the Gervais Principle) through the character arcs of Michael and Ryan in The Office. The construct and examples provide a broad-strokes treatment of the why of the power dynamics among sociopaths, the clueless and losers. This helps us understand how the world works, but not how to work it. So let me introduce you to the main skill required here, mastery over the four major languages spoken in organizations, among sociopaths, losers and the clueless. I’ll call the four languages Posturetalk, Powertalk, Babytalk and Gametalk.

|< First   < Previous   61–70 (82)   Next >   Last >|