Hey, Small IT software business but we're starting to grow

And yes, I realise that good decision making can take time, I a m not trying to rush the cook. I just want decisions to be made with confidence when all options are presented fully.

>>1459200
I would hire a manager with experience in the field, it sounds like there's currently no one making decisions.

>>1459207
Either this or you need to step up and start being the decision maker.

I'm sure there's training, and honestly if you have a good influence you can bring that out of them.

>>1459200
It depends on the Decision. If its something that will impact the business for year or years then a week isn't a long time.

>>1459220
>>1459217
>>1459207

But should a manager be making choices on how something is programmed? Perhaps I should have given an example before hand:

We make software to help manage special needs schools, reporting, timetabling etc.

Now attendance, attendance is not binary like one would think, especially regarding students with severe medical issues. There is a huge list of approved, unapproved and automatically approved absences reasons, not to mention handling leave maximums, report integration etc. On top of that the school needs to have reasonable control over the accepted reasons, however we must ensure that they can't override government policies.

So - how is best way to implement something like this? It is a HUGE job even for skilled programmers. Personally I don't think a third party hovering over the programmer's shoulders is the best way to encourage quick, quality solutions.

Thoughts?

>>1459220
It is code blinking on a computer screen. Anything can be rewritten / reimplemented.

Getting it done right the first time is obviously a huge priority but to have nothing done after a week of discussing, really is silly (IMO, maybe I am wrong, this is my first IT company)

>>1459229
>But should a manager be making choices on how something is programmed?

Yes, but not necessarily the specifics, more in terms of giving the team a direction to go - the "best way" is a meme, if it works as intended and you can implement it, that's the best way. There's no point in arguing over the minutiae of the code, if all ways work someone needs to step up and say "this is what we're doing", that's the manager, otherwise you spend weeks with 3 options which all get the job done but no implementation.

>>1459229
Where I used to work as a lawyer we all sat down on monday and discussed all the things we were going to do that week. If we had unresolved questions we discussed them, everyone could give their feedback and eventually we would agree on something, let the person himself decide or the manager would decide.

If the responsible manager decides its easy for the employers because they can just implement it without being accountable for the decision. So you can stop pondering about it. The manager is responsible so if he picks a decision that directly opposes the idea of the guy on the floor then its his neck.

>>1459251
Of course big decisions can require planning. Especially in the IT world. If a decision will impact the course you are going for many weeks you want to have considered all options. But once the details are on the table a decision can be made.

Best thing for the business is to keep /biz/ updated as the company expands so we can provide feedback. There is no better place for quality advice from experienced professionals.

Getting Things Done by David Allen has some chapters on making decisions/brainstorming, etc. Also, try

>Problem Solving

The 80/20 Principle – Richard Koch
Accidental Genius – Mark Levy
Learning from the Future – Liam Fahey & Robert Randall

though I haven't read any of these.

>>1459718
80/20 is a neat concept, but it can be thoroughly explained in about 2 paragraphs. It was the most redundant book i ever read. If you want to save a trip to a library here is a tl;dr


80% of results will come from 20% of your actions. Like wise 20% of employees will count for 80% of productivity.

I think there are 2 major ways to go: either have highly skilled pragmatic devs who can each carry their own project individually, or have a lead developer who takes responsibility for the architecture as a whole

kinda depends on if you have many small projects, or one or several big ones with high continuety. maybe have a lead dev per major client/project.

key things to look into are how often the discussions occur and how often they result from previous issues. if theyre unique cases involving new modules or new functionality, thats fine, even for a week. assuming other work still gets done.

if its issues that result from previous decisions or bad code maintainability and you have an increasingly large maintenance debt, take some time to sort it all out so you can future proof your code and eliminate or reduce these time draining discussions in the future. really a lot of it can be solved by simply looking up best practises and applying what is practical with the time and information that you have available at the moment.

also a big one is being confident you can handle issues that occur in the future, rather than trying to have designs account for every possible expansion that may or may not occur in the future. make sure your code is easy to expand and maintain and you can rest assured any issue you havent thought of will be easy to solve.

but if a week of researching and testing some architecture changes will save tons of time in implementing features or issues that you already know are coming, then hell yes take that week.

>>1459754
also, if its about tiny technical details of how things are actually coded, get them to cut that shit out.

should be following best practises and constantly testing and refactoring code so its Good Enough

oh you might want to have a code reviews at the end of every dev cycle so the devs can learn from eachother and identify problem areas or things they want to improve and turn that into smaller issues to tackle on the next cycle.

lets you cut out a lot of the discussion within a cycle and make every issue more actionable. even research and development or trying and testing specific things that youre not sure on how to implement yet can be a specific issue/ticket/story that simply gets a day or two assigned to it in whatever project management cycles you use.

saves a lot of time if you have a few concrete options and simply discuss them once in a review, then implement in your regular scheduling

and finally some things can be resolved by discussing them with your client if theyre about actual features. maybe certain things were thought up in a way that doesnt really work with whats already in place and the client wouldnt mind doing it in a slightly different, maybe even better way. maybe some things werent clear enough to the team and theyre discussing what the feature should actually do for the user? fixable with communication and planning your dev cycle with devs and customers together so they can discuss everything that needs to be done beforehand.

the most pragmatic devs do all these things themselves/intuitively and can handle project responsibility. the others may need some more structure from agile/scrum elements or leadership

OP are you one of the coders yourself? can you dev? what is your project management like? do you have some specific examples?

>>1459236

It's not that simple unfortunately. Inevitably some faggot will come along that introduces new requirements, new stuff that the code must do, more special cases that the code must handle. It is worth while to think about how you will structure the code so you can adapt